Guide de déploiement sécurisé de Citrix ADC

Bonnes pratiques en matière de sécurité Citrix ADC MPX, VPX et SDX

December 6, 2022

Contributeur:

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 entreprise peut déployer la solution multi-locataire ou flexible 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 gourmands en processeur. Une appliance Citrix ADC fournit également l’intégration transparente avec Citrix OpenCloud Access qui peut étendre le centre de données avec la puissance du cloud.

Pour garantir la sécurité tout au long du cycle de vie du déploiement, Citrix recommande de prendre en compte les points suivants pour :

Sécurité physique
Sécurité des appareils
Sécurité du réseau
Administration et gestion

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

Important :

à partir de la version logicielle 12.1, NetScaler est renommé Citrix ADC. Pour de plus amples informations, consultez https://www.citrix.com/about/citrix-product-guide/.

Directives de déploiement

Lors du déploiement d’un Citrix ADC, prenez en compte les meilleures pratiques de sécurité physiques et matérielles suivantes :

Meilleures pratiques en matière de sécurité physique

Déployez 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 tout accès non autorisé. Au minimum, l’accès à la salle des serveurs doit être contrôlé à l’aide d’un verrou, 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 une 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 des bulletins de sécurité Citrix https://support.citrix.com/securitybulletins et pensez à vous inscrire pour recevoir des alertes pour les bulletins nouveaux et mis à jour https://support.citrix.com/user/alerts.

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 des lumières éteintes (LOM) Citrix ADC

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

À l’invite du shell Citrix ADC, exécutez la commande suivante :
```
>ipmitool raw 0x30 0x41 0x1

```
Remarque : L’exécution de la commande précédente rétablit les paramètres d’usine par défaut du LOM et supprime tous les certificats SSL. Pour obtenir des instructions sur la façon de reconfigurer le port LOM, reportez-vous à la section Lumières du port de gestion de l’appliance Citrix ADC MPX.
Dans l’interface graphique LOM, accédez à Configuration > Certification SSLet ajoutez un certificat et une clé privée.

En outre, Citrix recommande vivement 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 à ceux-ci.
- 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 d’adresses IP connue.
- 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é vers 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 section Effacement de vos données avant d’envoyer l’appliance ADC à Citrix.

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é.
Le protocole HTTPS (HTTP over TLS) doit être utilisé lors de l’accès à l’interface graphique et l’interface HTTP par défaut doit être désactivée.

La section suivante fournit plus d’informations sur ces considérations clés, en plus des modifications supplémentaires recommandées.

Principales considérations relatives à la sécurité réseau

N’exposez pas le NSIP à Internet :

Citrix recommande vivement que l’adresse IP de gestion Citrix ADC (NSIP) ne soit pas exposée à l’Internet public et soit déployée derrière un pare-feu SPI (Stateful 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) réputée ou des certificats appropriés de l’autorité de certification de votre 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 transport, cela nécessite que les certificats TLS soient distribués aux utilisateurs et nécessite une interaction de l’utilisateur lors de l’établissement 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 et l’interface graphique Citrix ADC, 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 utiliser 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 et la documentation produit Citrix : SSH key-based authentication for local system users
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.

Certaines opérations peuvent nécessiter un accès shell (comme l’administration de certificats SSL). Toutefois, seules les personnes autorisées à administrer la SVM doivent avoir accès à l’interpréteur de commandes de l’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 :

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

Citrix recommande de ne pas utiliser le compte nsroot et de créer plutôt un compte de superutilisateur. Lorsque vous utilisez le nsroot compte, assurez-vous que les mots de passe sont forts et comportent 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

```
Remarque : Dans cet exemple, le système cmdpolicy (ex : nom cmdpolicy: shell) est créé pour refuser l’accès au shell. Cette stratégie est liée à l’utilisateur créé userabc) avec une priorité élevée. Le superutilisateur par défaut cmdpolicy est également lié en 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é.

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

connectez-vous en tant que : 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-->

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]

```

Connectez-vous en tant qu’utilisateur admin 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 :

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ée à l’utilisateur administrateur de l’instance spécifié.
Fournissez ces informations utilisateur à l’ADMIN VPX. SDX ADMIN doit conserver ce mot de passe nsroot administrateur et ne doit pas le partager avec l’administrateur VPX.

Remarque :

Pour modifier le mot de passe nsroot, ouvrez une session sur la SVM, sélectionnez l’instance et modifiez le mot de passe. Ne modifiez jamais le mot de passe nsroot à partir de la CLI de VPX.
Pour plus d’informations sur les utilisateurs RBAC, voir Utilisateurs, groupes d’utilisateurs et stratégies de commande.
Pour modifier le mot de passe de l’appliance Citrix ADC à partir de la SVM, consultez Modifier une instance Citrix ADC.
Pour provisionner l’appliance Citrix ADC avec l’administration des instances, reportez-vous à la section Ajouter une instance Citrix ADC.

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 procédant comme suit :

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

AllowTcpForwarding no
Enregistrez le fichier et copiez-le dans /nsconfig pour que les modifications soient persistantes au cas où vous redémarreriez pendant les tests.
Redémarrez le processus sshd à l’aide de la commande suivante :
```
kill -HUP `cat /var/run/sshd.pid`

```

Configurez l’appliance Citrix ADC avec la 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 haute disponibilité, consultez la rubrique Haute disponibilité > Configuration de la haute disponibilité dans la documentation Citrix et How to set up a High Availability Pair on Citrix ADC.

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

Si vous avez configuré vos appliances Citrix ADC dans une configuration haute disponibilité, en 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 Sécurisé . 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.

Mot de passe administrateur : voir Modifier le mot de passe administrateur.
Mot de passe du compte utilisateur interne ou du nœud RPC : voir Modifier le mot de passe d’un nœud RPC.

Remarque

Citrix recommande également de désactiver le compte d’utilisateur interne et d’utiliser plutôt l’authentification par clé.

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 extérieur
VLAN de gestion
VLAN du serveur interne

Citrix recommande de configurer le réseau pour intégrer le port LOM au 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 nécessaires, 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 marquage 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 Présentation de Citrix Web Application Firewall.

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

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

Déploiement sécurisé du cluster : si les nœuds de cluster Citrix ADC sont distribués en dehors du centre de données, Citrix recommande vivement d’utiliser un RPC sécurisé pour la messagerie de nœud à nœud (NNM), 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.

Lorsqu’ils sont déployés dans un déploiement de cluster L3, les paquets entre les nœuds Citrix ADC sont échangés via 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 de 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-->

Utiliser le 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-->

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 d’état de session
Protection contre la fixation de session (activer HTTP uniquement)
HSTS (activer la sécurité de transport stricte HTTP (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 : Citrix ADC activé : activé par défaut pour la plupart des entités

Le paramètre 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 créer un proxy pour une connexion. Par exemple, lorsque le 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 abandonnés ou réinitialisés.

Les entités de type de service suivantes obtiennent 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 ACTIVÉ)

Protection contre 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 par 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, cela indique au navigateur que ce cookie ne doit être accessible que 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 l’indicateur 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 stratégie 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 utilisés ensemble pour les VIP SSL. Pour les VIP non SSL, il est possible d’insérer l’indicateur HttpOnly.

Avec Citrix ADC, il est possible d’inclure des indicateurs HTTP uniquement et Secure pour les cookies définis par le serveur.

HttpOnly - Cette option sur un cookie oblige les navigateurs Web à renvoyer le cookie en utilisant le protocole HTTP (ou HTTPS) uniquement ; les méthodes non HTTP telles que les références document.cookie JavaScript ne peuvent pas accéder au cookie. Cette option permet d’empêcher le vol de cookies dû à des scripts intersites.
Sécurisé - Cette option sur un cookie permet aux navigateurs Web de 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 :

Activez la fonction de réécriture, si elle n’est pas déjà activée.
```
enable feature REWRITE

```

Créez une action de réécriture (cet exemple est configuré pour définir à la fois les indicateurs Secure et HttpOnly). Si l’une ou l’autre est manquante, modifiez-la si nécessaire pour les 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=/)!)"

or

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

Remarque : À partir de la version 13.1 de Citrix ADC, le paramètre bypassSafetyCheck n’est pas applicable. Toutefois, pour les versions antérieures à 13.1, ce paramètre est pris en charge.

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

Liez la stratégie de réécriture au serveur virtuel à sécuriser (si l’option Sécurisé 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 de plus amples informations, consultez https://support.citrix.com/article/CTX138055.

HSTS (activer la sécurité de transport stricte HTTP (HSTS)) :

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

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

Pour plus d’informations, consultez les rubriques suivantes.

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 back-end. Les protocoles SSLv3 et TLS v1.0 peuvent être désactivés sur les entités SSL car des failles de sécurité ont été signalées. Vous ne pouvez activer que TLS 1.1 et TLS 1.2. Si possible, utilisez uniquement la version TLS 1.2 sur les VIP qui interagissent avec les clients. 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   -tls11   DISABLED

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

Si le profil SSL est activé, utilisez la commande suivante :

set ssl profile <frontend profile> -ssl3  DISABLED   -tls1   DISABLED  -tls11  DISABLED

set ssl profile <backend profile> -ssl3  DISABLED   -tls1   DISABLED  -tls11  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 :

Suites de chiffrement d’échange de clés RSA recommandées :

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

Suites de chiffrement DHE Key Exchange recommandées :

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

Suites de chiffrement d’échange de clés ECDHE recommandées :

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

Suites de chiffrement dans l’ordre de préférence recommandées :

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

TLS1.2-AES128-GCM-SHA256
TLS1.2-AES-128-SHA256
TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
TLS1.2-ECDHE-RSA-AES-128-SHA256
TLS1-ECDHE-RSA-AES128-SHA
TLS1.2-DHE-RSA-AES128-GCM-SHA256
TLS1.2-DHE-RSA-AES-128-SHA256
TLS1-DHE-RSA-AES-128-CBC-SHA
TLS1-AES-128-CBC-SHA

Proxy HTTPS/Refuser tout autre trafic :

Dans la mesure du possible, disposez de VIP SSL pour un meilleur cryptage des données, en utilisant des versions SSL sécurisées (TLSv1.1 et TLSv1.2) et des chiffrements sécurisés. Le TPS SSL et le débit SSL doivent être pris en compte lors de l’activation du protocole SSL pour les VIP et les services SSL dorsaux.

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, remplacez le mot de passe par défaut de ce compte par un mot de passe sécurisé. Pour modifier le mot de passe par défaut de l’utilisateur administrateur, effectuez les opérations suivantes :

Ouvrez une session en tant que superutilisateur et ouvrez l’utilitaire de configuration.
Dans le volet de navigation, développez le nœud Systèmes.
Sélectionnez le nœud Utilisateurs.
Sur la page Utilisateurs du système, sélectionnez l’utilisateur nsroot.
Sélectionnez Changer le mot de passe.
Saisissez le mot de passe requis dans les champs Mot de passe et Confirmer le mot de
Cliquez sur OK.

Créer un autre compte de superutilisateur : 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 pour l’appliance Citrix ADC SDX et sa console de gestion de l’interface graphique après la configuration initiale. Pour modifier le mot de passe de l’utilisateur par défaut, effectuez les opérations suivantes :

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

Mot de passe fort pour l’utilisateur du système :

Citrix recommande d’utiliser un mot de passe fort pour les comptes d’utilisateurs du système créés dans Citrix ADC. Voici des exemples d’exigences relatives à la complexité des mots de passe :

Le mot de passe doit comporter au moins huit caractères.
Le mot de passe ne doit pas contenir de mots du dictionnaire ou une combinaison de mots du dictionnaire.
Le mot de passe doit comporter 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 renforcer la complexité des mots de passe :

set system parameter -minpasswordlen <positive_integer> -
-strongpassword ( ENABLED | DISABLED )
<!--NeedCopy-->

Dans les déploiements nécessitant plusieurs administrateurs, pensez à utiliser une méthode d’authentification externe pour authentifier les utilisateurs, par exemple RADIUS, TACACS+ ou LDAP (S). Pour plus d’informations, consultez Authentification des utilisateurs externes.

Verrouiller le compte d’utilisateur du système pour l’accès à la gestion : l’appliance Citrix ADC vous permet de verrouiller un utilisateur du système pendant 24 heures et de refuser l’accès à l’utilisateur. L’appliance Citrix ADC prend en charge la configuration à la fois pour l’utilisateur système et pour les utilisateurs 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 utilisateurs 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 utilisateurs et des mots de passe.

Désactiver l’accès à la gestion pour le compte 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 du système pour qu’ils puissent se connecter à 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 utilisateurs et des mots de passe.

Forcer la modification du mot de passe pour les utilisateurs administratifs : pour une authentification sécurisée nsroot, l’appliance Citrix ADC invite l’utilisateur à changer le mot de passe par défaut en un nouveau si l’option forcePasswordChange est activée dans le paramètre système. Vous pouvez modifier votre mot de passe nsroot depuis l’interface de ligne de commande ou 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é, consultez la section Gestion des comptes d’utilisateurs 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éez la clé principale du système pour la protection des données : de Citrix ADC 12.1 à Citrix ADC 13.0—71.44, 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 des comptes utilisateurs stockés localement.

Remarque : à partir de la version 13.0—76.31 de Citrix et versions ultérieures, une clé principale système aléatoire est créée automatiquement par défaut lors du processus de mise à niveau.

Pour créer la clé principale du système :

À l’aide de l’interface de ligne de commande, connectez-vous en tant qu’administrateur système.
Entrez la commande suivante :

create kek <passphrase>
<!--NeedCopy-->

Remarque :

Après l’exécution de la commande create system kek, KEK est utilisé pour la plupart des cryptages de mots 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 avez accès au shell et que vous supprimez les fichiers de fragments de clé par erreur, cela peut entraîner une perte de configuration, un échec de synchronisation, un échec d’ouverture de session. Voici certains 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 de la source, la synchronisation et le basculement peuvent échouer.
- Si l’un des fichiers de fragment de clé est perdu ou endommagé, le chiffrement/décryptage des données sensibles entraîne un échec qui peut à son tour entraîner une perte de configuration, un échec de synchronisation, un échec d’ouverture de session.
La phrase de passe doit comporter au moins 8 caractères.

Utilisez 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 une utilisation avec la plage d’adresses IP de confiance à l’aide de 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. Voici un ensemble d’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 fournit un accès pour 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 et SNIP. Si cette option est activée, fournissez l’accès aux adresses NSIP, SNIP, avec des 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 avec 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 que l’appliance prenne en charge ces protocoles, autorisez explicitement le trafic utilisant ces protocoles à l’aide d’une 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 de la plage 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 des listes de contrôle 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-->

Vous pouvez obtenir une sécurité supplémentaire en utilisant un certificat côté client. Pour plus d’informations sur les certificats côté client et l’authentification client, consultez Authentification client ou l’article CTX214874 du centre de connaissances : Comment créer et utiliser des certificats clients sur l’appliance Citrix ADC avec le microprogramme 10.1 et supérieur.

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

L’appliance Citrix ADC comprend quatre stratégies ou rôles de commande tels que l’opérateur, la lecture seule, le réseau et le 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 la section Utilisateurs, groupes d’utilisateurs et stratégies de commande.

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

Un intervalle d’expiration de session est fourni pour limiter la durée pendant laquelle une session (interface graphique, 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.

Interface graphique : 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.

Interface graphique : 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 des groupes qui n’ont pas de délai d’expiration configuré.

Interface graphique : accédez à Système > Paramètres, cliquez sur Définir les paramètres système globaux, puis définissez le paramètre Délai d’inactivité du client (secondes) ANY. CLI : À l’invite de commandes, entrez la commande suivante :

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

La valeur de délai d’expiration 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 configuré pour un groupe membre 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 du 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’expiration entre 5 minutes et 1 jour. Pour restreindre la valeur du délai d’expiration :

Interface graphique : accédez à Système > Paramètres, cliquez sur Définir les paramètres système globauxet sélectionnez le champ Délai d’expiration 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 est invité à modifier la valeur du délai d’expiration. Si l’utilisateur ne modifie pas la valeur du délai d’expiration, par défaut, la valeur du délai d’expiration 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 auxquelles 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 la valeur du délai d’expiration qui se situe dans les 20 minutes.

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

CLI : spécifiez la valeur du 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 du délai d’expiration 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 du protocole NTP garantit que les heures enregistrées pour les entrées de journal et les événements système sont précises et synchronisées avec les 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 contenues 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. Le SNMPv3 intègre des fonctionnalités 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, voir Configuration de Citrix ADC pour les requêtes SNMPv3.

Remarque :

Citrix vous recommande d’utiliser SNMPv3 au lieu de SNMPv1 et SNMPv2.

Si vous ne configurez pas au moins un gestionnaire SNMP, l’appliance accepte les requêtes SNMP de toutes les adresses IP du réseau et y répond. 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 un 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. Le serveur d’audit utilise les informations d’identification de l’administrateur pour récupérer les journaux d’un ou plusieurs dispositifs.

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 le serveur d’audit 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 l’appliance. Pour consigner tous les messages syslog, effectuez les opérations suivantes :

Supprimez les spécifications du fichier journal du fichier /nsconfig/syslog.conf pour les installations locales.
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
Configurez le serveur Syslog pour accepter les entrées de journal des fonctionnalités de journalisation précédentes. Pour plus d’informations, consultez la documentation du serveur Syslog.
Pour la plupart des serveurs basés sur 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 l’installation doivent correspondre aux valeurs configurées sur l’appareil.
Par défaut, le serveur Syslog distant de tout ordinateur basé sur 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 de prendre les mesures suivantes 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 à la gestion du réseau et placés sur un segment de réseau de gestion qui se trouve dans le même LAN physique ou VLAN que les autres ports du dispositif 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 et les serveurs de gestion LOM. 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 de 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

Configurez l’appliance Citrix ADC pour supprimer ou transmettre l’en-tête de mise à niveau

Un nouveau paramètre PassProtocolUpgrade est ajouté au profil HTTP pour empêcher les attaques sur les serveurs principaux. En fonction de l’état de ce paramètre, l’en-tête de mise à niveau est transmis dans la demande envoyée au back-end ou supprimé avant l’envoi de la demande.

Si le paramètre PassProtocolUpgrade est activé, l’en-tête de mise à niveau est transmis au back-end. Le serveur accepte la demande de mise à niveau et l’informe dans sa réponse.
Si ce paramètre est désactivé, l’en-tête de mise à niveau est supprimé et la demande restante est envoyée au backend.

Le paramètre PassProtocolUpgrade est ajouté aux profils suivants.

nshttp_default_profile - activé par défaut
nshttp_default_strict_validation - désactivé par défaut
nshttp_default_internal_apps - désactivé par défaut
nshttp_default_http_quic_profile : activé par défaut

Citrix vous recommande de désactiver le paramètre PassProtocolUpgrade.

Définissez le paramètre PassProtocolUpgrade à l’aide de l’interface de ligne de commande :

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

set ns httpProfile <name> [-passProtocolUpgrade ( ENABLED | DISABLED )]

Définissez le paramètre PassProtocolUpgrade à l’aide de l’interface graphique :

Accédez à Système -> Profils -> Profils HTTP.
Créez ou modifiez un profil HTTP.
Cochez la case Passer la mise à niveau du protocole .

Configurez Citrix ADC pour supprimer les demandes HTTP non valides

Citrix recommande vivement que l’appliance Citrix ADC soit configurée avec une vérification et une application strictes des demandes HTTP afin d’empêcher les demandes HTTP non valides de transiter 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 qui utilisent cette option de tester les modifications dans un environnement intermédiaire avant de le mettre 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 (valeur par défaut = 1)
small_window_idle_timeout (par défaut = 7 s)
small_window_cleanthresh (valeur par défaut = 100)
small_window_protection (par défaut = activé)

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 comprise entre 0 et 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 PCB dans la file d’attente de surtension qui sont sondés avec une sonde KA.

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

Configurez Citrix ADC pour vous protéger contre les attaques d’usurpation d’identité TCP

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

set ns tcpProfile profile1 -rstWindowAttenuate ENABLED -spoofSynDrop ENABLED

Done

set lb vserver lbvserver1 -tcpProfileName profile1

Done
<!--NeedCopy-->

Citrix recommande aux clients qui utilisent cette option de tester les modifications dans un environnement intermédiaire avant de le mettre 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 de réécriture globale suivante envoie uniquement le trafic réseau avec des en-têtes tels que Host, Accept 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-->

Configurer la notification de fermeture

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 que la connexion se termine pour éviter l’attaque par troncature. Chaque partie peut initier l’échange de messages de clôture. Chaque partie peut initier une clôture 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 d’arrêt TLS, connectez-vous à l’interface de ligne de commande en tant que superutilisateur ou administrateur système et exécutez les commandes suivantes :

set ssl parameter -sendCloseNotify y

save ns config
<!--NeedCopy-->

Interface graphique de gestion sécurisée, API NITRO et communication RPC

Pour sécuriser l’interface graphique de gestion, l’API NITRO et la communication RPC sur les appliances Citrix ADC et Citrix Gateway, le paramètre maxclientForHttpdInternalService est ajouté aux appliances. Cette option est désactivée par défaut. Vous devez activer le paramètre pour sécuriser l’interface graphique de gestion, l’API NITRO et la communication RPC.

Il est également recommandé de définir maxclientForHttpdInternalService pour correspondre à la valeur MaxClients dans /etc/httpd.conf à l’aide de la commande Shell suivante. La valeur par défaut de MaxClients est 30.

nsapimgr_wr.sh -ys maxclientForHttpdInternalService=<val>
<!--NeedCopy-->

Pour plus d’informations sur la définition de la maxclientForHttpdInternalService valeur et les versions de Citrix ADC qui prennent en charge ce paramètre, consultez https://support.citrix.com/article/CTX331588.

Recommandations de sécurité DNSSEC

Citrix recommande d’appliquer les recommandations suivantes 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 la 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.

Retournez 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 Domain Name System > Configuring DNSSEC dans 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 ressources 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 à l’ADC, puis signer la zone

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

Ajoutez un service ADNS.

Par exemple :

add service s1 <ip address> adns 53`
<!--NeedCopy-->

Créez des clés DNS.

Par exemple, pour agir en tant que serveur officiel pour le domaine com :

create dns key -zoneName com -keytype ksK -algorithm rsASHA512 -keysize 3000 -fileNamePrefix com.ksk.rsasha1.3000

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

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

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

Ajoutez des enregistrements NS et SOA pour la com zone, 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 de Citrix ADC en tant que serveur ADNS dans Citrix Docs.

Configuration héritée

Configurez 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 l’établissement de liaison SSL et redirige le client vers l’URL configurée. Si cette fonctionnalité est désactivée, l’appliance refuse d’effectuer le processus d’établissement de liaison SSL avec des clients SSL v2.

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

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

Configurer Citrix ADC pour empêcher la renégociation SSL non sécurisée

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 Comment configurer et utiliser le paramètre -DenySSLReneg.

Configurer la vérification du certificat de conformité NDCPP

La vérification du certificat de conformité NDCPP s’applique lorsque l’appliance agit sur un client (connexion dorsale). Lors de la vérification du certificat, ignorez le nom commun si le SAN est présent dans le certificat SSL.

À l’invite de commandes, tapez les commandes suivantes pour configurer l’attribut « NDCPPComplianceCertCheck » dans le paramètre SSL :

set ssl parameter [-quantumSize <quantumSize>] [-crlMemorySizeMB <positive_integer>] [-strictCAChecks (YES | NO)] [-sslTriggerTimeout <positive_integer>] [-sendCloseNotify (YES | NO)] [-encryptTriggerPktCount <positive_integer>] [-denySSLReneg <denySSLReneg>] [-insertionEncoding (Unicode|UTF-8)] [-ocspCacheSize <positive_integer>][- pushFlag <positive_integer>] [- dropReqWithNoHostHeader (YES | NO)] [-pushEncTriggerTimeout <positive_integer>] [-ndcppComplianceCertCheck ( YES | NO)] [-heterogeneousSSLHW (ENABLED | DISABLED )]
<!--NeedCopy-->

Exemple :

set ssl parameter -quantumSize 8 -crlMemorySizeMB 256 -strictCAChecks no -ssltriggerTimeout 100 -sendClosenotify no -encryptTriggerPktCount 45 -denySSLReneg NONSECURE -insertionEncoding unicode -ocspCacheSize 10 -pushFlag 3 -dropReqWithNoHostHeader YES  -pushEncTriggerTimeout 100 ms -ndcppComplianceCertCheck YES
<!--NeedCopy-->

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 façon de configurer les appliances pour qu’elles utilisent ce matériel afin de protéger à la fois l’appliance elle-même, les serveurs principaux et les utilisateurs finaux.

Gestion des certificats et des clés TLS

Configuration des suites de chiffrement TLS pour les déploiements NDCPP

Les suites de chiffrement TLS suivantes sont prises en charge pour les déploiements NDCPP.

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Pour la liste des chiffrements pris en charge sur le MPX-14000 FIPS, consultez https://docs.citrix.com/en-us/citrix-adc/downloads/cipher-support-on-a-citrix-mpx-sdx-14000-fips-appliance.pdf.

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 :

Délier tous les chiffrements du serveur virtuel

unbind ssl vs v1 –cipherName FIPS
<!--NeedCopy-->

Liez uniquement 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-->

Installation de certificats et de paires de clés en utilisant une autorité de certification approuvée :

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

Authentifiez-vous auprès de l’interface de ligne de commande Citrix ADC en tant qu’administrateur système ou superutilisateur.

Créez une clé privée RSA.

create fipsKey m1 -keytype RSA -modulus 2048 -exponent F4
<!--NeedCopy-->

Créez la demande de signature de certificat (CSR) :

create certreq csr_1 -fipsKeyName m1 -countryName IN -stateName BA -organizationName citrix
<!--NeedCopy-->

Soumettez le CSR à l’autorité de certification.

Pour la plupart des autorités de certification commerciales et d’entreprise, le CSR est envoyé par e-mail. 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 selon les autorités de certification d’entreprise. 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 administrateur système 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 pour 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 véritable mutualisation, utilisez l’appliance Citrix ADC MPX certifiée FIPS pour mettre fin au protocole TLS et transférer le trafic vers l’appliance Citrix ADC SDX. Il est également possible d’utiliser un HSM externe de 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 : niveau 2

hsmLabel

Étiquette pour identifier le module de sécurité matériel (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

Pour les contrôles de conformité RFC, il est recommandé de conserver « APPFW_RFC_BLOCK » comme valeur par défaut rfcprofile pour le profil WAF.
WAF prend en charge l’insertion Samesite d’une valeur d’attribut de cookie et le cookie peut être limité au contexte du même site ou intersite en sélectionnant des valeurs « Strict » ou « Lax ».

Déployer 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 qu’elle protège. Les connexions doivent passer par l’appareil. 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 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).

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

Configurez une valeur différente pour le paramètre SessionCookieName dans chaque niveau.

set appfw settings -sessionCookieName "citrix_ns_id_1"
<!--NeedCopy-->

Premier niveau de sécurité

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

Activez le débordement de la mémoire tampon, l’injection SQL et les scripts intersites.
L’URL de démarrage est nécessaire lorsque l’application est particulière sur laquelle les URL doivent être consultées et doivent se protéger contre la navigation forcée.
Activez les contrôles de format de champ si votre application attend des entrées dans un champ de formulaire.

La vérification de script intersite peut générer des faux positifs, car de nombreuses entreprises disposent d’une importante base installée de contenu Web amélioré par JavaScript qui enfreint la même règle d’origine. Si vous activez la vérification de script intersite HTML sur un tel site, vous devez générer les exceptions appropriées afin que la vérification ne bloque pas les activités légitimes.

Déployez le premier niveau, recherchez les faux positifs, déployez les exceptions, puis passez au niveau suivant. Une mise en œuvre progressive permet de 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ébordement de la mémoire tampon, de l’injection SQL et des scripts intersites. 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 mise en œuvre progressive permet de gérer le déploiement de 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 de sécurité avancés du profil tels que le balisage 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 contrôles de sécurité désactivés dans le profil de base de Citrix Web App Firewall fonctionnent tous sur les objets de la réponse HTTP. Par conséquent, ces contrôles de sécurité nécessitent davantage de ressources. Lorsque Citrix Web App Firewall effectue des protections côté réponse, il doit se souvenir des 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, il est vérifié pour détecter les incohérences avant que les informations ne soient envoyées au serveur Web. Ce concept est désigné sous le nom de sessionisation. 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 diffuse et héberge des informations critiques dans des formulaires doit faire l’objet d’une vérification.
Vérification du balisage des formulaires 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 par falsification de requêtes intersites. Cette vérification doit être activée si l’application possède des formulaires Web. Cette vérification nécessite relativement peu de capacité de traitement du processeur par rapport à certains autres contrôles de sécurité qui analysent en profondeur les formulaires Web. Il est donc capable de gérer des attaques de volume élevé sans dégrader gravement 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 flux de travail de 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 :

Configurez le profil de sécurité.
Appliquez des signatures pour toutes les menaces connues - le modèle négatif.
Configurez des stratégies de trafic capables de détecter le flux de trafic approprié pour lequel ce profil de sécurité doit être activé.

Vous êtes prêt à ce que le trafic de production passe par le système. Le premier niveau d’écoulement est terminé. Configurez ensuite 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 :

Configurez l’infrastructure d’apprentissage.
Déployez les règles apprises pour la protection.
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 afin de 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 d’utiliser TLS1.1/1.2 pour les liens entre l’appliance Citrix Gateway et d’autres services, tels que les serveurs LDAP et d’interface Web. L’utilisation d’anciennes versions de ce protocole, 1.0, SSLv3 et antérieures, n’est pas recommandée.

Utilisez la fonction « Applications Intranet » Utilisez 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é en matière d’authentification, d’autorisation et d’audit

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 :

Portail de sécurité Citrix : http://www.citrix.com/security
Documentation produit Citrix ADC

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

La version officielle de ce document est en anglais. Certains contenus de la documentation Citrix ont été traduits de façon automatique à des fins pratiques uniquement. Citrix n'exerce aucun contrôle sur le contenu traduit de façon automatique, qui peut contenir des erreurs, des imprécisions ou un langage inapproprié. Aucune garantie, explicite ou implicite, n'est fournie quant à l'exactitude, la fiabilité, la pertinence ou la justesse de toute traduction effectuée depuis l'anglais d'origine vers une autre langue, ou quant à la conformité de votre produit ou service Citrix à tout contenu traduit de façon automatique, et toute garantie fournie en vertu du contrat de licence de l'utilisateur final ou des conditions d'utilisation des services applicables, ou de tout autre accord avec Citrix, quant à la conformité du produit ou service à toute documentation ne s'applique pas dans la mesure où cette documentation a été traduite de façon automatique. Citrix ne pourra être tenu responsable de tout dommage ou problème dû à l'utilisation de contenu traduit de façon automatique.

Cela vous a-t-il été utile ?

Bonnes pratiques en matière de sécurité Citrix ADC MPX, VPX et SDX

December 6, 2022

Contributeur:

December 6, 2022

Contributeur:

Dans cet article

Directives de déploiement
Consignes de configuration
Administration et gestion
Recommandations cryptographiques Citrix ADC
Autres caractéristiques
Ressources d’information supplémentaires

Cela vous a-t-il été utile ?