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

Une appliance Citrix ADC MPX est un Controller de distribution d’applications qui accélère les sites Web, assure la gestion du trafic L4-L7, offre un pare-feu intégré Citrix Web App et décharge les serveurs. Une instance Citrix ADC VPX est une appliance virtuelle dotée de toutes les fonctionnalités d’une appliance Citrix ADC MPX, s’exécute sur des serveurs standard et offre une meilleure 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 véritable multitenancy qui optimise votre infrastructure de livraison d’applications Web en séparant les services réseau partagés à volume élevé des services intensifs et spécifiques aux applications. 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 de plus amples informations, consultez la section 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 en matière 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.

Des mesures supplémentaires 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 devrait en aviser le personnel de sécurité. Dans le cas de vidéosurveillance, les images enregistrées sont disponibles à des fins d’audit.

Accès sécurisé au panneau avant 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. Cela empêche l’accès aux ports physiques de l’appliance Citrix ADC ou, dans le cas d’un déploiement VPX, à la console hôte de virtualisation.

Protection de l’alimentation électrique

L’appliance Citrix ADC (ou serveur d’hébergement) doit être protégée par un onduleur approprié. En cas de panne de courant, cela garantit le fonctionnement continu de l’appliance ou permet l’arrêt contrôlé des Citrix ADC physiques ou virtuels. L’utilisation d’un onduleur aide é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 un dispositif 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 les accès non autorisés.

Meilleures pratiques en matière de sécurité de l’appliance Citrix ADC

Effectuer des mises à jour logicielles de l’appliance

Citrix recommande vivement aux clients, avant le déploiement, de s’assurer que leurs appliances ont été mises à jour avec les dernières versions du microprogramme. Lorsqu’il est effectué à 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 envisagez de vous inscrire aux alertes sur 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 Citrix ADC SDX.

En plus d’appliquer des procédures de sécurité physique normales, vous devez protéger l’accès à l’hôte de virtualisation grâce à un contrôle d’accès basé sur les rôles et à une gestion efficace 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 pour le type de virtualisation. Les clients utilisant la plate-forme Citrix ADC SDX pour héberger Citrix ADC VPX doivent s’assurer qu’ils utilisent la dernière version du micrologiciel pour leur Citrix ADC SDX.

Réinitialiser la gestion des lumières de sortie (LOM) Citrix ADC

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

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

    >ipmitool raw 0x30 0x41 0x1
    

    Remarque : L’exécution de la commande ci-dessus réinitialise le LOM aux paramètres par défaut d’usine et supprime tous les certificats SSL. Pour obtenir des instructions sur la reconfiguration du port LOM, consultez[Éclairage du port de gestion de l’appliance Citrix ADC MPX](/en-us/netscaler-hardware-platforms/mpx/netscaler-mpx-lights-out-management-port-lom.html

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

    En outre, Citrix recommande vivement que la configuration utilisateur suivante soit effectuée. Utilisation de l’interface graphique LOM :

    • Accédez à Configuration > Utilisateurs > Modifier l’utilisateur et modifiez le mot de passe du compte de superutilisateur nsroot.
    • 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 d’adresses IP connue.
    • Accédez à Configuration > Utilisateurs > Modifier l’utilisateur , créez un compte de superutilisateur alternatif et liez des stratégies à ce compte.

    Pour plus d’informations sur la configuration du LOM, reportez-vous à la sectionConfiguration LOM.

Maintenance et suppression des données persistantes

Si un Citrix ADC est redéployé dans un autre environnement, désaffecté ou renvoyé à Citrix sous RMA, vous devez vous assurer 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.

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

  • L’interface administrateur Citrix ADC (NSIP) ne doit pas être exposée à Internet.
  • Le certificat SSL par défaut Citrix ADC doit être remplacé.
  • HTTPS (HTTP over 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 considérations clés, en plus des changements qui sont recommandés.

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

Ne pas exposer le NSIP à Internet :

Citrix recommande vivement que Citrix ADC Management IP (NSIP) ne soit pas exposé à Internet public et qu’il soit déployé 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, des certificats TLS par défaut sont créés. Ils 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 qu’elle utilise des certificats provenant d’une autorité de certification (CA) de bonne réputation ou des certificats appropriés de votre autorité de certification d’entreprise.

Lorsqu’il est lié à un serveur virtuel accessible au public, un certificat TLS valide provenant d’une autorité de certification réputée simplifie l’expérience utilisateur pour les applications Web orientées sur Internet ; les navigateurs Web utilisateur ne nécessitent aucune interaction utilisateur lors de l’initialisation de la 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ée, consultez l’article CTX122521 du Centre de connaissances : « Procédure de remplacement du certificat par défaut d’une appliance Citrix ADC par un certificat d’autorité de certification approuvée 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 nécessite que les certificats TLS soient distribués aux utilisateurs et nécessite l’interaction de l’utilisateur lors de l’initialisation des connexions au serveur Web. Pour plus d’informations sur la création de certificats personnalisés, consultez l’article CTX121617 :Procédure de création et d’installation de 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 TLS Citrix ADC » de ce guide.

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

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

  • Créez une paire de clés privées et publiques RSA 2048 bits ou supérieure et utilisez les clés 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ées en usine.

  • Configurez l’appliance pour qu’elle n’utilise que des suites de chiffrement fortes et modifiez l’ensemble de suites de chiffrement ‘DEFAULT’ pour qu’il reflète cela 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 NIST 800-52 (Révision 1) comme guide. 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 :Comment sécuriser l’accès SSH à l’appliance Citrix ADC avec authentification par clé publique.

  • 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

Pour plus d’informations sur la configuration de l’accès sécurisé à l’interface graphique d’administration, consultez l’article CTX111531 :Procédure d’activation de l’accès sécurisé à l’interface graphique Citrix ADC à l’aide de l’adresse SNIP/MIP de l’appliance.

Considérations supplémentaires en matière de sécurité du réseau

Les considérations de sécurité supplémentaires suivantes liées au réseau doivent également être prises en compte lors du déploiement de vos appliances 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 :

  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émarriez pendant les tests.

Tuez le processus à l’aide de lakill -SIGHUP <sshdpid> commande ou redémarrez le système.

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

Dans les déploiements où un fonctionnement continu est requis, les appliances Citrix ADC peuvent être déployées dans une configuration haute disponibilité. Une telle configuration assure un fonctionnement continu si l’une des appliances cesse de fonctionner ou nécessite une mise à niveau hors connexion.

[Pour plus d’informations sur la configuration de la haute disponibilité, consultez la rubrique Haute disponibilité > Configuration de la haute disponibilité surDocuments Citrix[]lesComment 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. 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 l’authentification basée sur la 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 de plus amples informations, consultez la section Accédez à une appliance Citrix ADC à l’aide de clés SSH sans mot de passe.

Modifier les mots de passe par défaut :

Pour une sécurité renforcée, Citrix vous recommande de modifier les mots de passe nsroot, ainsi que le compte d’utilisateur interne ou le nœud RPC. Il est conseillé de changer fréquemment les mots de passe.

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

Citrix recommande vivement 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 à avoir trois VLAN :

  • VLAN Internet extérieur
  • VLAN de gestion
  • VLAN du serveur intérieur

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 nécessaires, vous devez vous assurer que les deux réseaux ont les mêmes niveaux de sécurité ou similaires.

Si les deux réseaux ont des niveaux de sécurité différents, le balisage VLAN ne doit pas être utilisé. Pensez plutôt à dédier un port à chaque réseau spécifique et utilisez des VLAN indépendants distribués sur les ports de l’appliance.

Remarque : les appliances Citrix ADC VPX ne prennent pas en charge les VLAN balisés.

Pensez à utiliser le Citrix Web App Firewall : une appliance sous licence Citrix ADC édition platine fournit un pare-feu intégré Citrix Web App qui utilise un modèle de sécurité positif et apprend automatiquement le comportement de l’application pour la protection contre les menaces telles que la commande injection, injection SQL et script inter-site.

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

Restreindre l’accès aux applications non managériales : exécutez la commande suivante pour restreindre la capacité des applications non managériales à accéder à une appliance Citrix ADC.

set ns ip <NSIP> -restrictAccess enabled

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 fortement l’utilisation de RPC sécurisé pour la messagerie NNNM (Node to 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

Remarque : une configuration supplémentaire peut être nécessaire. 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 sur un tunnel GRE non chiffré qui utilise les adresses NSIP des nœuds source et de destination pour le routage. Lorsque cet échange se produit sur Internet, en l’absence d’un tunnel IPsec, les NSIP seront 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 la fonctionnalité de cluster sur 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

Utilisez Secure MEP for Global Server Load Balancing (GSLB) : Pour chiffrer le MEP entre les appliances Citrix ADC pour GSLB, exécutez la commande suivante à partir de l’interface NSCLI :

set rpcNode <GSLB Site IP> -secure yes

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

Les paramètres du mode d’infrastructure du Citrix Web App Firewall peuvent être utilisés pour sécuriser le trafic pass-through sur l’appliance Citrix ADC. Ces paramètres de mode d’infrastructure fournissent un niveau de sécurité de base sans casser aucune application. La liste suivante résume les paramètres du mode d’infrastructure disponibles.

  • Protection de l’état de session
  • Protection de 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 la session :

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

Le paramètre de protection de l’état de la session est activé par défaut et ne nécessite aucune configuration spécifique. Lorsque l’appliance Citrix ADC est configurée pour mandater une connexion ; par exemple, lorsque le flux touche 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 entrant dans cette machine d’état sont traités. Les autres paquets sont soit abandonnés, soit réinitialisés.

Les entités de type de service suivantes réalisent 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 ENABLE)

Protection de 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éécrire 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 XSS courantes beaucoup plus difficiles à retirer.

Voici un exemple de cookie avec l’indicateur HttpOnly défini :

Set-Cookie: ASP.NET_SessionId=ig2fac55; path=/; HttpOnly

Les cookies insérés par Citrix ADC pour la persistance d’insertion de cookie, par défaut, définissent 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, un 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 de l’indicateur HttpOnly à l’aide de l’interface de ligne de commande :

À l’invite de commandes, tapez :

set lb parameter -HttpOnlyCookieFlag (ENABLED)  

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 : Lescookies sécurisés et HttpOnly peuvent être faits ensemble pour les VIP SSL. Pour les VIP non-SSL, on pourrait simplement insérer le drapeau HttpOnly.

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

  • HttpOnly - Cette option sur un cookie provoque 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 permet de prévenir le vol de cookies en raison de scripts intersites.
  • Sécurisé - Cette option sur un cookie provoque les navigateurs Web à renvoyer uniquement la valeur du cookie lorsque la transmission est crypté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
    
  2. Créez une action de réécriture (cet exemple est configuré pour définir les indicateurs Secure et HttpOnly. Si l’une ou l’autre est manquante, modifiez-la 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
    

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

    Exemple :

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

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

    Exemple :

    bind lb vserver mySSLVServer -policyName rw_force_secure_cookie -priority 100 -gotoPriorityExpression NEXT -type RESPONSE
    

    Pour plus d’informations, reportez-vous à la section https://support.citrix.com/article/CTX138055.

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

Recommandation : Activé Citrix ADC : dans la version 12.0 du logiciel Citrix ADC, 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 HTTP strict Transport Security (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)

OU

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

Pour de plus amples informations, consultez la section Configurer la prise en charge de HTTP strict Transport Security (HSTS).

  • Dans les versions 11.1 et antérieures du logiciel Citrix ADC, HTTP strict Transport Security (HSTS) peut être activé en créant une stratégie de réécriture et en la liant globalement ou au vserver 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

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

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 multifactorielle — 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 multifacteur, reportez-vous à la sectionAuthentification multifacteur (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 frontend et sur 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. Vous ne pouvez activer que TLS 1.1 et TLS 1.2. Si possible, n’avez que la version TLS 1.2 sur le client confronté à 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

Citrix ADC recommandé Ciphersuites :

Les chiffrements suivants sont pris en charge par Citrix ADC qui n’incluent aucun composant dans la liste des « rejets obligatoires ». Ceux-ci sont organisés par échange de clés (RSA, DHE et ECDHE) puis en plaçant les plus performants au sommet et les plus sécuritaires au 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 DHE Key Exchange :

  • 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 les suites de chiffrement ECDHE Key Exchange :

  • 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

Recommandez Ciphersuites dans l’ordre de préférence :

La liste suivante de chiffrements comprend les échanges de clés RSA, DHE et ECDHE. Il offre le meilleur compromis entre sécurité, performances et 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/refuse 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 doit être pris en compte lors de l’activation de SSL pour les VIP et les services SSL backend.

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. Des instructions supplémentaires sur les meilleures pratiques de configuration de Citrix ADC sont disponibles dans l’articleParamètres et meilleures pratiques recommandés pour une implémentation générique d’une appliance Citrix ADC.

Comptes système et utilisateurs

Modifier le mot de passe pour le compte de super utilisateur nsroot : vous ne pouvez pas supprimer le superutilisateur nsroot intégré. Par conséquent, modifiez le mot de passe par défaut pour le compte nsroot en un mot de passe sécurisé. Pour modifier le mot de passe par défaut de l’utilisateur nsroot, effectuez la procédure suivante :

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

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 l’installation 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. Saisissez 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 locaux et les administrateurs doivent choisir des mots de passe forts. Voici des exemples d’exigences en matière de 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 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 imposer la complexité du mot 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>

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

Accédez à Citrix ADC à l’aide des clés SSH et sans mot de passe : dans les déploiements où il est nécessaire d’administrer un grand nombre d’appliances Citrix ADC, envisagez d’utiliser les clés SSH et sans mot de passe. Pour plus d’informations sur la configuration de cette fonctionnalité, reportez-vous à la sectionAccédez à une appliance Citrix ADC à l’aide de clés SSH sans mot de passe.

Créer la clé principale système pour la protection des données : à partir de Citrix ADC 11.0, il est nécessaire de créer une clé principale 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 les comptes utilisateur AAA stockés localement. Pour créer la clé principale 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 <file name>

Note :

  • Après l’exécution de la commande create system kek, KEK est utilisé pour tous les chiffrements de mot de passe.
  • Vous ne pouvez pas supprimer le fichier KEK. Si vous avez accès à l’interpréteur de commandes 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 d’ouverture de session. Voici quelques-uns des points à noter :

    • Utilisez toujours un ancien fichier de configuration correspondant à la version installée lors de la rétrogradation ; sinon l’ouverture de session, la configuration source, la synchronisation, le basculement peuvent échouer.
    • Si l’un des fichiers de fragment de clé est perdu ou endommagé, le chiffrement /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 d’ouverture de session.
  • 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 le contrôle de l’accès à l’appliance :

  • Pensez à 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 « DENY » par défaut pour les ports 80, 443 et 3010, mais avec un « ALLOT » explicite pour les adresses IP approuvées pour accéder à ces ports.

Cette stratégie peut être étendue pour une utilisation avec une gamme d’adresses IP approuvées à 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
  • 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

Dans l’exemple précédent, la commande donne accès à 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 l’une de ces adresses est activée, donnez accès aux adresses NSIP, SNIP ou MIP 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 liste 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
  • Si le 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 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
  • 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. Ceci s’applique à l’appliance exécutant le logiciel Citrix ADC version 8.0 ou ultérieure. Voici un ensemble d’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

Utilisez 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 l’opérateur, la lecture seule, le réseau et le superutilisateur. En outre, vous pouvez 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 pour restreindre l’accès en lecture seule à l’utilisateur en lecture seule :

add system user readonlyuser

bind system user readonlyuser read-only 0

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 session système peut être configuré aux niveaux suivants :

  • Délai d’expiration au niveau de l’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>
  • Délai d’expiration au niveau du 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>
  • 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 et définissez le paramètre ANY Client Idle Time-out (secondes). CLI : À l’invite de commandes, entrez la commande suivante :

set system parameter -timeout <secs>

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 de délai d’attente 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’attente 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 :

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

Une fois que l’utilisateur a activé le paramètre RestrictedTimeout, Si la valeur du délai d’attente 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’attente. 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.

En outre, vous pouvez 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. Maintenant, lors de l’accès à une interface, l’utilisateur doit spécifier une valeur de délai d’attente qui est dans les 20 minutes.

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

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

Journalisation et surveillance

Configurer NTP

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é. Cela garantit que les temps enregistrés 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

Modifiez le fichier ntp.conf pour chaque serveur NTP approuvé que vous ajoutez. Il devrait y avoir une entrée de restriction correspondante pour chaque entrée de serveur. Vous pouvez localiser le fichier ntp.conf en exécutant le « find. —name ntp.conf » à partir de l’invite de shell 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, consultez les rubriques Système > SNMP sur les documents Citrix.

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

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

set ns ip <IP_Address> -snmp disabled

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

Le serveur d’audit Citrix ADC consigne tous les états et les informations d’état collectées par différents modules dans le noyau ainsi que dans les démons de niveau utilisateur. Le serveur d’audit permet à un administrateur de faire référence à 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 nsroot pour récupérer les journaux de la ou des appliance (s).

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

définir audit nslogparams —serverip<hostname> -serverport <port>

  • Configuration du serveur d’audit distant

Pour configurer la journalisation sur le serveur d’audit dans un ordinateur distant, installez le serveur d’audit sur cet ordinateur. Voici des exemples d’options de 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

Notez que cette fonctionnalité permet de consigner les messages d’audit générés par le fichier ns.log de l’appliance uniquement. Pour enregistrer 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, semblable 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 provenant des installations de journalisation ci-dessus. Pour déterminer comment procéder, 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 à celles configurées sur l’appliance.
  5. Par défaut, le serveur syslog distant de 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

Remarque : Reportez-vous aux 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é) du trafic réseau non approuvé.
  • Définissez différentes valeurs de nom d’utilisateur, de mot de passe, de certificat SSL et de clé SSL pour le LOM et les ports de gestion 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 réseau local local ou local virtuel physique que les autres ports de périphériques 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 des interfaces LAN des appliances gérées. Les adresses IP dynamiques attribuées par DHCP ne sont pas recommandées, car elles rendent difficile l’implémentation des listes de contrôle d’accès au 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 vivement 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 requêtes HTTP non valides de passer par des serveurs virtuels. Cela peut être fait en liant un profil HTTP intégré, nshttp_default_strict_validation, au ou aux serveurs virtuels à l’aide de la commande suivante sur le NSCLI :

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

set lb vserver <vserver name> -httpProfileName nshttp_default_strict_validation

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

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 (default=1)
  • small_window_idle_timeout (default=7 sec)
  • small_window_cleanthresh (default=100)
  • small_window_protection (default=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. Cependant, certains réglages des paramètres peuvent être nécessaires 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 shell de l’appliance :

$ nsapimgr –ys small_window_threshold=<desired value>

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 de shell de l’appliance :

  • nstcp_cur_zero_win_pcbs : Ce compteur suit le nombre de PCB qui ont actuellement une valeur de fenêtre faible.
  • nstcp_err_conndrop_at_pass : ce compteur est incrémenté lorsque l’appliance détecte qu’en passant des paquets d’un côté à l’autre, elle a dépassé la valeur nscfg_small_window_idletimeout.
  • nstcp_err_conndrop_at_retx : Ce compteur est incrémenté lorsque le temps écoulé 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 utilisant cette option de tester les modifications dans un environnement intermédiaire avant de le publier 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

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

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

Il est possible de configurer Citrix ADC pour accepter uniquement des en-têtes HTTP spécifiques. Cela peut être accompli en ajoutant une action de réécriture pour restreindre 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 au serveur le trafic réseau avec des en-têtes tels que Hôte, Accepter et test :

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

Remarque : ces commandes ne sont prises en charge que dans Citrix ADC version 10.5 et ultérieure.

Configuration de 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 afin d’éviter une attaque de troncature. L’ une ou l’autre des parties peut initier l’échange de messages de clôture. L’une ou l’autre des parties 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. Afin de s’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

Recommandations de sécurité DNSsec

Citrix recommande d’appliquer les recommandations suivantes aux clients utilisant DNSsec :

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

Le NIST recommande aux administrateurs DNS de maintenir des ZSK RSA/SHA-1 de 1024 bits et/ou RSA/SHA-256 jusqu’au 1er octobre 2015.

Activer l’alarme SNMP pour l’expiration de la 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, DNSKeyTimeToExpiration et DNSKeyUnitsofExpiration, sont envoyées avec l’interruption SNMP DNSKeyExpiration. Pour plus d’informations, consultez la référence OID SNMP de Citrix ADC.

Repasser 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, voir Système de noms de domaine > Configuration de la rubrique DNSSEC sur les documents Citrix.

Serveur DNSsec ADN sécurisé

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

Lorsque 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 des 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. Ajouter un service ADN.

    Par exemple :

    add service s1 <ip address> adns 53`
    
  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
    

    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.

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

Remarque : 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é, voir Système de noms de domaine > Configuration du Citrix ADC en tant que serveur ADN sur les documents Citrix.

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

Remarque : à partir de la version 9.2 du logiciel Citrix ADC, les fonctionnalités de redirection et de redirection de chiffrement SSLv2 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 de manière à 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

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

La commande suivante autorise la renégociation pour les clients et serveurs sécurisés uniquement :

set ssl parameter -denySSLReneg NONSECURE

Pour plus d’informations, consultez l’article CTX123680 du Centre de connaissances,Comment configurer et utiliser le paramètre -denysslReneg. »

Recommandations de chiffrement Citrix ADC

Cette section décrit un certain nombre d’é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 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 NDPP

Pour obtenir la liste des suites de chiffrement TLS prises en charge pour les déploiements NDPP, voirhttps://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
    
  2. 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
    

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

  1. À l’aide d’un utilitaire de transfert de fichiers sécurisé, tel que scp ou WinSCP, transférez le certificat d’émetteur du serveur (racine) vers 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.

  1. Ouvrez une session sur 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>

Remarque : Installez uniquement les certificats d’autorité de certification racine provenant d’autorités de certification reconnues comme fiables. Vous devez supprimer tous les autres certificats.

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

Des informations détaillées sur la manière dont les fichiers de certificat et de clé peuvent être importés dans l’appliance Citrix ADC se trouvent dans les rubriques Déchargement et accélération SSL > Importation de certificats et de clés existants sur les documents Citrix.

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

  2. Authentifiez-vous 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
    
  3. Ajoutez le certificat à l’appliance Citrix ADC comme suit :

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

    save ns config
    

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

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 clé privée et une demande de signature de certificat (CSR). Ceci est fait comme suit :

  1. Authentifiez-vous 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
    
  3. Créez la demande de signature de certificat (CSR) :

    create certreq csr_1 -fipsKeyName m1 -countryName IN -stateName BA -organizationName citrix
    
  4. Soumettez le CSR à l’AC.

Pour la plupart des autorités de certification commerciales et d’entreprise, cela se fait généralement dans une demande par courriel. 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 FIPS

Si vous êtes un client FIPS existant et que vous utilisez une appliance Citrix ADC SDX pour une véritable multilocation, utilisez l’appliance Citrix ADC MPX certifiée FIPS pour terminer TLS et transférer le trafic vers l’appliance Citrix ADC SDX. Alternativement, il est possible d’utiliser un HSM externe Thales. Modifier les mots de passe de la carte crypto FIPS Lors de l’utilisation d’une version certifiée FIPS de Citrix ADC avec un Hardware Security Module (HSM), modifiez l’agent de sécurité par défaut et définissez un nouveau mot de passe utilisateur comme indiqué ci-dessous. 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 sysadmin peut effectuer cette tâche.

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

save configuration

initHSM

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

Étiquette HSMLabel

Étiquette permettant d’identifier le module de sécurité matérielle (HSM).

Longueur maximale : 31

Remarque : Toutes les données de la carte FIPS seront effacées avec la commande ci-dessus.

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

Le mot de passe du HSM doit être stocké dans un endroit sécurisé conformément aux procédures d’exploitation 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.

Fonctionnalités supplémentaires : Citrix Web App Firewall et Citrix Gateway

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. Cette section contient également des informations sur la création de plusieurs niveaux ou de sécurité.

Recommandations de sécurité de 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. Cette disposition minimise les chances de trouver un itinéraire autour de l’appliance.

Utiliser une stratégie « Default Deny »

Citrix recommande aux administrateurs de configurer le 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 de pare-feu Citrix Web App. Voici un exemple d’ensemble de commandes pour configurer une stratégie « refuser tout » au niveau global :

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>

Remarque : Le paramètre PRIORITÉ doit garantir 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 version 9.2 inclut des profils par défaut, tels que appfw_block, qui, lorsqu’ils sont configurés, ne correspondent pas aux stratégies de Citrix Web App Firewall. Exécutez la commande suivante pour définir le profil par défaut :

set appfw settings -defaultProfile appfw_block

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ébordement de la mémoire tampon, l’injection SQL et le script inter-site.
  • L’URL de démarrage est nécessaire lorsque l’application est très particulière sur quelles URL doivent être accessibles et doivent 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 XSS pourrait générer des faux positifs car de nombreuses entreprises ont une grande base installée de contenu Web amélioré par 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.

Il est recommandé de déployer le premier niveau, de rechercher des faux positifs, de déployer les exceptions, puis de passer au niveau suivant. Une implémentation par étapes 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ébordement de tampon, de l’injection SQL et des scripts inter-sites. 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.

Il est recommandé de déployer le deuxième niveau, de rechercher des faux positifs, de déployer les exceptions, puis de passer au niveau suivant. Une implémentation intermédiaire aide à gérer le déploiement du 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 balisage CSRF, la cohérence des cookies. Formulaire Cohérence des champs sur les parties des applications qui en ont besoin.
  • Les contrôles de sécurité avancés nécessitent plus de traitement 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 Citrix Web App Firewall de base fonctionnent tous sur des objets de la réponse HTTP. Par conséquent, ces contrôles de sécurité exigent davantage de ressources. Lorsque le Citrix Web App Firewall exécute 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 le 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 prochaine demande suivante, il est vérifié pour les incohérences avant l’envoi des informations au serveur Web. Ce concept est appelé Sessionization. Les vérifications de sécurité telles que le boîtier d’URL dans l’URL de démarrage, la cohérence des cookies, la cohérence des champs de formulaire et le balisage des formulaires CSRF impliquent la sessionisation. La quantité de ressources UC et mémoire utilisées par ces contrôles de sécurité augmente linéairement avec le nombre de requêtes envoyées via le Citrix Web App Firewall. Par exemple :

  • Activer la vérification de cohérence des champs de formulaire : Cette vérification est nécessaire 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 des formulaires aurait besoin de la vérification.

  • Vérification du marquage des formulaires CSRF : Ceci est une autre vérification des formulaires. La vérification du marquage de formulaire CSRF (Cross Site Request Falgery) marque chaque formulaire Web envoyé par un site Web protégé aux utilisateurs ayant un FormID unique et imprévisible, puis examine les formulaires Web renvoyés par les utilisateurs pour s’assurer que le FormID 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 a des formulaires basés sur le 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 les 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 workflow de 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 capables de détecter le flux de trafic correct où ce profil de sécurité doit être activé.

Vous êtes prêt pour le trafic de production à passer par le système. Le premier niveau de débit est terminé. De plus, configurez l’infrastructure d’apprentissage. Plusieurs fois, les clients veulent faire de l’apprentissage dans le trafic de production ainsi avoir les signatures appliquées évitera tout risque. Effectuez les opérations suivantes : a. Configurez l’infrastructure d’apprentissage. b. Déployer les règles apprises pour la protection. c. Valider les données d’apprentissage ainsi que les signatures appliquées avant de passer en ligne.

Recommandations de sécurité Citrix Gateway

Utiliser une stratégie « Default Deny »

Citrix recommande aux administrateurs de configurer Citrix Gateway avec une stratégie « refuser tous » au niveau global, 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 pour 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

Utiliser la communication TLS1.1/1.2 entre les serveurs

Citrix recommande fortement d’utiliser TLS1.1/1.2 pour les liaisons 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, SSLv3 et antérieures n’est pas recommandée.

Utilisez la fonctionnalité « Applications Intranet » Utilisez les applications Intranet pour définir les réseaux interceptés par le plug-in Citrix Gateway et envoyés à la Gateway. Voici un exemple de commandes de jeu 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

Ressources d’information supplémentaires

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

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