Configuration du proxy inverse Nginx pour un accès VPN-less à Cisco Finesse (12.6 ES03)

Introduction

Ce document décrit comment utiliser un proxy inverse pour accéder au bureau Cisco Finesse sans se connecter à un VPN basé sur les versions 12.6 ES03 de Cisco Finesse, Cisco Unified Intelligence Center (CUIC) et Cisco Identity Service (IdS).

Note: L'installation et la configuration de Nginx ne sont pas prises en charge par Cisco. Les questions relatives à ce sujet peuvent être discutées sur les forums communautaires de Cisco.

Note: Pour les déploiements ES ES ES03 de VPN-Less, consultez la liste des composants individuels afin de planifier les mises à niveau et vérifier les restrictions de compatibilité.

Lecture de Cisco Finesse 12.6 ES03
Lecture CUIC/IdS 12.6 ES03

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Version de Cisco Unified Contact Center Enterprise (UCCE)
• Cisco Finesse
• Administration Linux
• Administration réseau et administration réseau Linux

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Finesse - 12,6 ES03
• CUIC - 12,6 ES03
• IdS - 12.6 ES03
• Solution de collaboration hébergée (HCS) UCCE pour Contact Center (CC) - 11.6 ou version ultérieure
• Packaged Contact Center Enterprise (PCCE) - 12.5 ou version ultérieure
  
  Remarque: Les déploiements PCCE/UCCE 2K devront se trouver sur la version 12.6 de CCE en raison du déploiement co-résident LD/CUIC

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Note: La configuration fournie dans ce document a été configurée, renforcée et testée avec le proxy inverse Nginx (OpenResty) déployé sur CentOS 8.0, par rapport à un exemple de déploiement UCCE 2000 utilisateurs. Les informations de référence du profil de performance sont disponibles dans ce document.

Informations générales

Ce modèle de déploiement est pris en charge pour les solutions UCCE/PCCE et HCS pour UCCE.

Le déploiement d'un proxy inverse est pris en charge (disponible à partir de la version 12.6 ES01) en tant qu'option permettant d'accéder au bureau Cisco Finesse sans se connecter à un VPN. Cette fonctionnalité offre aux agents la flexibilité nécessaire pour accéder au bureau Finesse depuis n'importe quel endroit via Internet.

Pour activer cette fonctionnalité, une paire de proxies inversés doit être déployée dans la zone démilitarisée (DMZ).

L'accès au support reste inchangé dans les déploiements de proxy inverse. Pour se connecter au support, les agents peuvent utiliser la solution Cisco Jabber sur mobile et accès distant (MRA) ou la fonctionnalité Mobile Agent d'UCCE avec un réseau téléphonique public commuté (RTPC) ou un terminal mobile. Ce schéma montre à quoi ressemblera le déploiement réseau lorsque vous accéderez à deux clusters Finesse et deux noeuds CUIC via une seule paire de noeuds proxy inversés haute disponibilité.

L'accès simultané des agents sur Internet et des agents qui se connectent à partir du réseau local est pris en charge, comme illustré dans cette image.

Note: Pour prendre en charge ce déploiement, reportez-vous au guide des fonctionnalités qui présente les critères de sélection des proxys tiers à la place de Nginx.

- Guide de fonctionnalités UCCE 12.6 - Fournit une présentation, une conception et des détails de configuration pour la fonctionnalité VPN-less.
- Guide de sécurité UCCE 12.6 - Fournit des directives de configuration de sécurité pour le déploiement de proxy inverse.

Il est recommandé de consulter la section VPN-less du guide des fonctionnalités et du guide de sécurité avant de lire ce document.

Modifications dans ES03

• Nouvelles fonctionnalités
  
  
  • Les fonctionnalités de superviseur Finesse sont désormais prises en charge par proxy inverse.
  • Les rapports CUIC RealTime et Historical sont désormais pris en charge par les gadgets Finesse dans un environnement proxy.
    
    
  • Authentification pour toutes les demandes/communications - nécessite l'assistance de Lua
    
    • Toutes les demandes Finesse / CUIC / IM & Presence ( IM&P) sont authentifiées au niveau du proxy avant d'être autorisées à entrer dans le centre de données.
    • Les connexions d'E/S de socket et de socket de données en direct sont également limitées et autorisées uniquement par les clients qui ont réussi à faire une demande sécurisée à Finesse.
    • Détection et journalisation des attaques par force brutale au niveau du proxy, qui peut être utilisé avec Fail2Ban pour bloquer les adresses IP malveillantes.
      
      
• Améliorations de la sécurité pour la configuration du proxy inverse - nécessite la prise en charge de Lua
  
  • Authentification TLS (Mutual Transport Layer Security) entre le proxy inverse et les composants amont (Finesse/IdS/CUIC/Livedata).
  • Paramètres SeLinux.
  • Activez la vérification mutuelle d'approbation SSL (Secure Sockets Layer) pour les requêtes de serveur proxy et de composant.
    
    
• Une sécurité renforcée pour la configuration du proxy afin d'empêcher les attaques par déni de service (DoS)/déni de service distribué (DDoS) - nécessite une prise en charge Lua
  
  • Limites de débit de requête Nginx améliorées pour différentes parties du système.
  • Limites de débit pour IpTables.
  • Vérification des demandes de ressources statiques avant de demander le serveur de composants en amont.
  • Pages non authentifiées plus légères et pouvant être mises en mémoire cache qui ne touchent pas le serveur de composants en amont.
    
    
• Autres fonctionnalités diverses - nécessite l'assistance de Lua
  • Réponses CORS (Cross-Origin Resource Sharing) à détection automatique fournies par le proxy pour faciliter la configuration automatique et améliorer les performances
    
    
• Corrections de défaut relatives à VPN-less
  
  
  • CSCwa26057 - Plusieurs certificats offerts à l'agent lors de la connexion Finesse Desktop
  • CSCwa24471 - La page de connexion Finesse n'affiche pas le nom de domaine complet de l'agent SSO
  • CSCwa24519 :: Le service Webproxy ne peut pas redémarrer si le nom d'hôte du proxy inverse n'est pas résolvable à partir du composant
  • CSCwa23252 :: La confiance de finesse du proxy est rompue lorsque la profondeur est supérieure à une pour la chaîne de certificats CA
  • CSCwa46459 vulnérabilité log4j zero day exposée dans webservice

Notes de mise à niveau pour les configurations VPN basées sur ES01

• La configuration ES03 nécessite l'installation de Nginx avec le support de Lua.
• Exigences de certificat
  • Cisco Finesse, CUIC et IdS nécessiteront l'ajout du certificat hôte Nginx / OpenResty au magasin d'approbation Tomcat et un redémarrage effectué, avant que la configuration Nginx ES02 puisse se connecter correctement au serveur en amont.
  • Les certificats de serveur en amont Cisco Finesse, CUIC et IdS doivent être configurés dans le serveur Nginx pour utiliser la configuration basée sur ES03.

Note: Il est recommandé de supprimer la configuration Nginx basée sur ES01 avant d'installer les configurations ES03 Nginx.

Note: Les scripts de configuration ES03 nécessitent également l'installation ES03 COP correspondante dans Cisco Finesse, CUIC et IdS.

Authentification

Finesse 12.6 ES03 introduit l'authentification au niveau du proxy. L'authentification est prise en charge pour les déploiements SSO (Single Sign On) et non SSO.

L'authentification est appliquée pour toutes les requêtes et tous les protocoles qui sont acceptés au niveau du proxy avant d'être transférés aux serveurs de composants en amont, où l'authentification appliquée localement par les serveurs de composants a lieu également. Toutes les authentifications utilisent les identifiants de connexion Finesse courants pour authentifier les requêtes.

Les connexions persistantes, telles que les sockets Web qui s'appuient sur des protocoles d'application tels que XMPP (Extensible Messaging and Presence Protocol) pour l'authentification et la post-connexion, sont authentifiées au niveau du proxy en validant l'adresse IP à partir de laquelle une authentification d'application réussie a été effectuée avant d'établir la connexion de socket.

Authentification non SSO

L'authentification non SSO ne nécessite aucune configuration supplémentaire et fonctionnera avec les scripts de configuration Nginx sortants une fois les remplacements de script requis effectués. L'authentification repose sur le nom d'utilisateur et le mot de passe utilisés pour se connecter à Finesse. L'accès à tous les terminaux sera validé avec les services d'authentification Finesse.

La liste des utilisateurs valides est mise en cache localement au niveau du proxy (met à jour le cache toutes les 15 minutes), qui est utilisé pour valider l'utilisateur dans une requête. Les informations d'identification de l'utilisateur sont validées en transférant la demande à l'URI Finesse configuré, puis le hachage des informations d'identification est mis en cache localement (mis en cache pendant 15 minutes) pour authentifier localement les nouvelles demandes. En cas de modification du nom d'utilisateur ou du mot de passe, celle-ci ne prendra effet qu'après 15 minutes.

Authentification SSO

L'authentification SSO nécessite que l'administrateur configure la clé de chiffrement de jeton d'IDS sur le serveur Nginx dans le fichier de configuration. La clé de chiffrement du jeton IdS peut être obtenue à partir du serveur IdS avec le show ids secret Commande CLI. Ils doivent être configurés dans le cadre d'un des remplacements #must-change que l'administrateur doit effectuer dans les scripts avant que l'authentification SSO puisse fonctionner.

Reportez-vous au guide de l'utilisateur SSO pour connaître les configurations SAML d'IDS à exécuter pour que la résolution de proxy fonctionne pour les IDS.

Une fois l'authentification SSO configurée, une paire valide de jetons peut être utilisée pour accéder à n'importe quel point d'extrémité du système. La configuration du proxy valide les informations d'identification en interceptant les demandes de récupération de jeton envoyées aux IDS ou en déchiffrant les jetons valides et en les mettant ensuite en cache localement pour des validations supplémentaires.

Authentification pour les connexions Websocket

Les connexions de socket Web ne peuvent pas être authentifiées avec l'en-tête d'autorisation standard, car les en-têtes personnalisés ne sont pas pris en charge par les implémentations natives de socket Web dans le navigateur. Les protocoles d'authentification au niveau de l'application, où les informations d'authentification contenues dans la charge utile n'empêchent pas l'établissement de la connexion de socket Web, et par conséquent les entités malveillantes peuvent provoquer des attaques DOS ou DOS simplement en créant d'innombrables connexions pour submerger le système.

Afin d'atténuer cette possibilité, les configurations de proxy inverse nginx fournies ont des contrôles spécifiques pour permettre l'acceptation des connexions de socket web UNIQUEMENT à partir des adresses IP qui ont réussi à faire une demande REST authentifiée avant l'établissement de la connexion de socket web. Cela signifie que les clients qui tentent de créer des connexions de socket Web, avant qu'une demande REST ne soit émise, vont maintenant recevoir une erreur d'autorisation et ne sont pas pris en charge.

Prévention des attaques par force brute

Les scripts d'authentification Finesse 12.6 ES02 empêchent activement les attaques en force qui peuvent être utilisées pour deviner le mot de passe de l'utilisateur. Pour ce faire, il bloque l'adresse IP utilisée pour accéder au service, après un certain nombre de tentatives infructueuses en peu de temps. Ces demandes seront rejetées par 418 erreur client. Les détails des adresses IP bloquées sont accessibles à partir des fichiers <nginx-install-directory>/logs/blocking.log et <nginx-install-directory>/logs/error.log.

Le nombre de demandes ayant échoué, l'intervalle de temps et la durée de blocage sont configurables. Des configurations sont présentes dans le fichier <nginx-install-directory>/conf/conf.d/maps.conf.

## These two constants indicate five auth failures from a client can be allowed in thirty seconds.
## if  the threshold is crossed,client ip will be blocked.
map $host $auth_failure_threshold_for_lock {
    ## Must-change Replace below two parameters as per requirement
    default 5 ;
}

map $host $auth_failure_counting_window_secs {
    ## Must-change Replace below two parameters as per requirement
    default 30;
}

## This indicates duration of blocking a client to avoid brute force attack
map $host $ip_blocking_duration {
    ## Must-change Replace below parameter as per requirement
    default 1800;
}

Journalisation

Pour rechercher les adresses IP bloquées, exécutez les commandes suivantes à partir du répertoire <nginx-install-directory>/logs.

grep "will be blocked for" blocking.log
grep "IP is already blocked." error.log

2021/10/29 17:30:59 [emerg] 1181750#1181750: *19 [lua] block_unauthorized_users.lua:153: _redirectAndSendError(): 10.68.218.190 will be blocked for 30 minutes for exceeding retry limit., client: 10.68.218.190, server: saproxy.cisco.com, request: "GET /finesse/api/SystemInfo?nocache=1636456574482 HTTP/2.0", host: "saproxy.cisco.com:8445", referrer: "https://saproxy.cisco.com:8445/desktop/container/?locale=en_US&"

2021/10/29 19:21:00 [error] 943068#943068: *43 [lua] block_unauthorized_users.lua:53: 10.70.235.30 :: IP is already blocked..., client: 10.70.235.30, server: saproxy.cisco.com, request: "GET /finesse/api/SystemInfo?nocache=1635591686497 HTTP/2.0", host: "saproxy.cisco.com:8445", referrer: "https://saproxy.cisco.com:8445/desktop/container/?locale=en_US"

Il est recommandé aux clients de s'intégrer avec Fail2ban ou similaire pour ajouter l'interdiction aux règles IPtable / firewall.

Installer et configurer Fail2ban

Fail2ban analyse les fichiers journaux et interdit les adresses IP qui indiquent les signes malveillants — trop de échecs de mot de passe, recherche d'exploits, etc. Généralement, Fail2Ban est ensuite utilisé pour mettre à jour les règles de pare-feu afin de rejeter les adresses IP pendant une durée spécifiée, bien que toute autre action arbitraire (par exemple, envoyer un e-mail) puisse également être configurée. Pour plus d'informations, visitez https://www.fail2ban.org/.

Fail2ban peut être configuré pour surveiller le fichier block.log afin d'identifier les adresses IP bloquées par Nginx lors de la détection des attaques de bruteforce et de les interdire pendant une durée configurable. Les étapes d'installation et de configuration de fail2ban sur un serveur de remplacement CentOS sont les suivantes :

1. Installer Fail2ban en utilisant l'année

yum update && yum install epel-release
yum install fail2ban 

2. Créer une prison locale

Les configurations de la prison permettent à l'administrateur de configurer diverses propriétés telles que les ports qui doivent être interdits d'accès par toute adresse IP bloquée, la durée pendant laquelle l'adresse IP reste bloquée, la configuration de filtre utilisée pour identifier l'adresse IP bloquée à partir du fichier journal surveillée, etc. Les étapes à suivre pour ajouter une configuration personnalisée interdisant les adresses IP qui sont bloquées d'accéder aux serveurs en amont sont les suivantes :

a) Accéder au répertoire d'installation de Fail2ban (dans cet exemple /etc/fail2ban)

cd /etc/fail2ban

b) Faire une copie de prison.conf dans prison.local pour garder les changements locaux isolés.

cp jail.conf jail.local 

c) Ajoutez les configurations de prison suivantes à la fin du fichier prison.local, et remplacez les ports du modèle par les ports réels. Mettre à jour les configurations de temps d'interdiction selon les besoins.

# Jail configurations for HTTP connections.
[finesse-http-auth]
enabled = true
# The ports to be blocked. Add any additional ports.
port = http,https,<finesse-ports>,<cuic-ports>,<any-other-ports-to-be-blocked>
# Path to nginx blocking logs.
logpath = /usr/local/openresty/nginx/logs/blocking.log
# The filter configuration.
filter = finesseban
# Block the IP from accessing the port, once the IP is blocked by lua.
maxretry= 1
# Duration for retry set to 3 mins. Doesn't count as the maxretry is 1
findtime= 180
# Lock time is set to 3 mins. Change as per requirements.
bantime = 180

3. Configurer un filtre

Un filtre indique à Fail2ban ce qu'il faut rechercher dans les journaux pour identifier l'hôte à interdire. Les étapes de création d'un filtre sont les suivantes :

a) Créer un filtre.d/finesseban.conf

touch filter.d/finesseban.conf 

b) Ajoutez les lignes suivantes au filtre de fichiers.d/finesseban.conf

[Definition]
# The regex match that would cause blocking of the host.
failregex = <HOST> will be blocked for

4) Démarrer Fail2ban

Exécutez la commande suivante pour démarrer fail2ban.

fail2ban-client start

Ouvrez les fichiers journaux fail2ban et vérifiez qu'il n'y a aucune erreur. Par défaut, les journaux de fail2ban entrent dans le fichier /var/log/fail2ban.log.

Valider les URL des ressources statiques

Tous les terminaux valides accessibles de manière non authentifiée sont suivis activement dans les scripts ES03.

Les requêtes vers ces chemins non authentifiés sont activement rejetées, si un URI non valide est demandé, sans envoyer ces requêtes au serveur en amont.

Mise en cache des en-têtes CORS

Lorsque la première demande d'options réussit, les en-têtes de réponse access-control-allow-headers, access-control-allow-Origine, access-control-allow-méthodes, access-control-expose-headers et access-control-allow-authentication sont mis en cache au niveau du proxy pendant cinq minutes. Ces en-têtes sont mis en cache pour chaque serveur amont respectif.

Configuration

Ce document décrit la configuration de Nginx en tant que proxy inverse à utiliser pour activer l'accès Finesse VPN-less. Les versions du composant de la solution UCCE, du proxy et du système d'exploitation utilisées pour vérifier les instructions fournies sont fournies. Les instructions pertinentes doivent être adaptées au système d'exploitation/proxy de votre choix.

• Version Nginx utilisée - OpenResty 1.19.9.1
• Système d'exploitation utilisé pour la configuration - CentOS 8.0

Note: La configuration Nginx décrite peut être téléchargée à partir de la page de téléchargement du logiciel Finesse version 12.6(1)ES3.

Installer OpenResty en tant que proxy inverse dans DMZ

Cette section détaille les étapes d'installation du proxy basé sur OpenResty. Le proxy inverse est généralement configuré en tant que périphérique dédié dans la zone démilitarisée du réseau (DMZ), comme indiqué dans le schéma de déploiement mentionné précédemment.

1. Installez le système d'exploitation de votre choix avec la spécification matérielle requise. Les modifications des paramètres du noyau et IPv4 peuvent différer selon le système d'exploitation sélectionné et il est conseillé aux utilisateurs de vérifier à nouveau ces aspects si la version du système d'exploitation choisie est différente.
2. Configurez deux interfaces réseau. Une interface sera requise pour l'accès public des clients Internet et une autre pour communiquer avec les serveurs du réseau interne.
3. Installez OpenResty.

N'importe quelle saveur de Nginx peut être utilisée à cette fin, à condition qu'elle soit basée sur Nginx 1.19+ et supporte Lua :

• Nginx Plus
• Nginx Open Source (Nginx Open Source devra être compilé avec les modules Lua basés sur OpenResty pour être utilisé)
• OpenResty
• Extras GetPageSpeed

Note: La configuration fournie a été testée avec OpenResty 1.19 et devrait fonctionner avec d'autres distributions avec seulement des mises à jour mineures, le cas échéant.

Installation d'OpenResty

1. Installez OpenResty. Voir Packages OpenResty Linux.

   Dans le cadre de l'installation d'OpenResty, Nginx sera installé à cet emplacement et ajoutera le chemin OpenResty à la variable PATH en ajoutant dans le fichier ~/.bashrc.

   export PATH=/usr/local/openresty/bin:$PATH

2. Démarrer / arrêter Nginx.
   • Pour démarrer Nginx, saisissez openresty.
   • Pour arrêter Nginx, saisissez openresty -s stop.

Configurer Nginx

La configuration est expliquée pour une installation Nginx basée sur OpenResty. Les répertoires par défaut pour OpenResty sont les suivants :

• <nginx-install-directory> = /usr/local/openresty/nginx
• <Openresty-install-directory> = /usr/local/openresty

1. Téléchargez et extrayez le fichier à partir de la page de téléchargement du logiciel Finesse version 12.6(1)ES03 (12.6-ES03-inverse-proxy-config.zip) qui contient la configuration du proxy inverse pour Nginx.
2. Copiez nginx.conf, nginx/conf.d/et nginx/html/ du répertoire de configuration du proxy inverse extrait vers <nginx-install-directory>/conf, <nginx-install-directory>/conf/conf.d/, et <nginx-install-directory>/html/ respectivement.
3. Copiez le répertoire nginx/lua à partir du répertoire de configuration de proxy inverse extrait dans le <nginx-install-directory>.
4. Copiez le contenu de lualib dans <Openresty-install-directory>/lualib/resty.
5. Configurez la rotation du journal nginx en copiant le fichier nginx/logrotate/saproxy vers le <nginx-install-directory>/logrotate/dossier. Modifiez le contenu du fichier pour pointer vers les répertoires de journaux appropriés si les valeurs par défaut de Nginx ne sont pas utilisées.
6. Nginx doit être exécuté avec un compte de service non privilégié dédié, qui doit être verrouillé et avoir un shell non valide (ou selon le cas pour le système d'exploitation choisi).
7. Recherchez la chaîne "must-change" dans les fichiers sous les dossiers extraits nommés html et conf.d et remplacez les valeurs indiquées par des entrées appropriées.
8. Assurez-vous que tous les remplacements obligatoires sont effectués, qui sont décrits avec les commentaires à modifier dans les fichiers de configuration.
9. Assurez-vous que les répertoires de cache configurés pour CUIC et Finesse sont créés sous <nginx-install-directory>/cache avec ces répertoires temporaires.
   • <nginx-install-directory>/cache/client_temp
   • <nginx-install-directory>/cache/proxy_temp

Note: La configuration fournie concerne un exemple de déploiement 2000 et doit être développée de manière appropriée pour un déploiement plus important.

Configurer le cache Nginx

Par défaut, les chemins du cache proxy sont stockés dans le système de fichiers. Nous vous recommandons de les remplacer par des lecteurs en mémoire en créant un emplacement de cache dans tmpfs, comme indiqué ici.

1. Créez des répertoires pour les différents chemins de cache proxy sous /home.

   Par exemple, ces répertoires doivent être créés pour la Finesse principale. Les mêmes étapes doivent être suivies pour les serveurs Finesse et CUIC secondaires.

   mkdir -p /home/primaryFinesse/rest
   mkdir -p /home/primaryFinesse/desktop
   mkdir -p /home/primaryFinesse/shindig
   mkdir -p /home/primaryFinesse/openfire
   mkdir -p /home/primaryCUIC/cuic
   mkdir -p /home/primaryCUIC/cuicdoc
   mkdir -p /home/client_temp
   mkdir -p /home/proxy_temp

   echo "tmpfs /home/primaryFinesse/rest tmpfs size=1510M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >>
/etc/fstab echo "tmpfs /home/primaryFinesse/desktop tmpfs size=20M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >>
/etc/fstab echo "tmpfs /home/primaryFinesse/shindig tmpfs size=500M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >>
/etc/fstab echo "tmpfs /home/primaryFinesse/openfire tmpfs size=10M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >>
/etc/fstab echo "tmpfs /home/primaryCUIC/cuic tmpfs size=100M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >>
/etc/fstab echo "tmpfs /home/primaryCUIC/cuicdoc tmpfs size=100M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >>
/etc/fstab echo "tmpfs /home/client_temp tmpfs size=2048M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >>
/etc/fstab echo "tmpfs /home/proxy_temp tmpfs size=2048M,rw,auto,noexec,nodev,nosuid,gid=root,uid=root,mode=1700 0 0" >> /etc/fstab

   Note: Augmentez les caches client et proxy_temp de 1 Go pour chaque nouveau cluster Finesse ajouté à la configuration.

2. Montez les nouveaux points de montage avec la commande mount -av.
3. Valider le système de fichiers a monté les nouveaux points de montage avec le df -h erasecat4000_flash:.
4. Modifiez les emplacements proxy_cache_path dans les fichiers de configuration du cache Finesse et CUIC.

   Par exemple, pour modifier les chemins d'accès du principal Finesse, accédez à <nginx-install-directory>conf/conf.d/finesse/caches et modifiez l'emplacement de cache existant /usr/local/openresty/nginx/cache/finesse25/ à l'emplacement du système de fichiers nouvellement créé. /home/primaryFinesse.
   
   ##Must-change /usr/local/openresty/nginx/cache/finesse25 location would change depending on folder extraction proxy_cache_path /home/primaryFinesse/desktop levels=1:2 use_temp_path=on keys_zone=desktop_cache_fin25:10m max_size=15m inactive=3y use_temp_path=off; proxy_cache_path /home/primaryFinesse/shindig levels=1:2 use_temp_path=on keys_zone=shindig_cache_fin25:10m max_size=500m inactive=3y use_temp_path=off; proxy_cache_path /home/primaryFinesse/openfire levels=1:2 use_temp_path=on keys_zone=openfire_cache_fin25:10m max_size=10m inactive=3y use_temp_path=off; proxy_cache_path /home/primaryFinesse/rest levels=1:2 use_temp_path=on keys_zone=rest_cache_fin25:10m max_size=1500m inactive=40m use_temp_path=off;
   
   

5. Suivez les mêmes étapes pour les serveurs secondaire et CUIC Finesse.

Note: Assurez-vous que la somme de toutes les tailles de lecteur tmpfs créées dans toutes les étapes précédentes est ajoutée à la taille de mémoire finale pour le déploiement, car ces lecteurs sont des blocs de mémoire configurés pour ressembler à des disques de l'application et consomment autant d'espace mémoire.

Configurer les certificats SSL

Utiliser des certificats auto-signés - Tester les déploiements

Les certificats auto-signés ne doivent être utilisés que jusqu'à ce que le proxy inverse soit prêt à être mis en production. Dans un déploiement de production, utilisez uniquement un certificat signé par une autorité de certification (CA).

1. Générer des certificats Nginx pour le contenu du dossier SSL. Avant de générer des certificats, vous devez créer un dossier appelé ssl sous /usr/local/openresty/nginx. Vous devez générer deux certificats à l'aide de ces commandes (l'un pour <réverseproxy_primary_fqdn> et l'autre pour <réverseproxy_secondary_fqdn>).
   1. sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /usr/local/openresty/nginx/ssl/nginx.key -out /usr/local/openresty/nginx/ssl/nginx.crt (passez le nom d'hôte comme : <réverseproxy_primary_fqdn>)
   2. sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /usr/local/openresty/nginx/ssl/nginxnode2.key -out /usr/local/openresty/nginx/ssl/nginxnode2.crt (passez le nom d'hôte comme : <inverseproxy_secondary_fqdn>)
   3. Assurez-vous que le chemin du certificat est /usr/local/openresty/nginx/ssl/nginx.crt et /usr/local/openresty/nginx/ssl/nginxnode2.crt, car ceux-ci sont déjà configurés dans les fichiers de configuration Finesse Nginx.
2. Modifiez l'autorisation de la clé privée 400 (r—).
3. Configurez le pare-feu/iptables sur le proxy inverse pour permettre aux communications du pare-feu de correspondre aux ports sur lesquels le serveur Nginx a été configuré pour écouter.
4. Ajoutez l'adresse IP et le nom d'hôte Finesse, IdS et CUIC sous l'entrée /etc/hosts sur le serveur proxy inverse.
5. Reportez-vous au guide des fonctionnalités de la solution pour connaître les configurations à effectuer sur les serveurs de composants pour configurer l'hôte Nginx en tant que proxy inverse.

Note: La configuration fournie concerne un exemple de déploiement 2000 et doit être développée de manière appropriée pour un déploiement plus important.

Utiliser le certificat signé CA - Déploiements de production

Un certificat signé par une autorité de certification peut être installé sur le proxy inverse en procédant comme suit :

1. Générez la demande de signature de certificat (CSR).

   Afin de générer la CSR et la clé privée, saisissezopenssl req -new -newkey rsa:4096 -keyout nginx.key -out nginx.csraprès vous être connecté au proxy. Suivez l'invite et fournissez les détails. Cela génère la CSR (nginx.csr dans l'exemple) et la clé privée RSA (nginx.key dans l'exemple) de 4 096 bits de force.

   Exemple :
   
   [root@reverseproxyhost.companyname.com ssl]# openssl req -new -newkey rsa:4096 -keyout nginx.key -out nginx.csr Generating a RSA private key .....+++++ ...................................................................................................................................................+++++ writing new private key to 'nginx.key' Enter PEM pass phrase:passphrase Verifying - Enter PEM pass phrase:passphrase ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:CA Locality Name (eg, city) [Default City]:Orange County Organization Name (eg, company) [Default Company Ltd]:CompanyName Organizational Unit Name (eg, section) []:BusinessUnit Common Name (eg, your name or your server's hostname) []:reverseproxyhostname.companydomain.com Email Address []:john.doe@comapnydomain.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:challengePWD An optional company name []:CompanyName
   
   Notez la phrase de passe PEM, car elle sera utilisée pour déchiffrer la clé privée pendant le déploiement.
   
   

2. Obtenir le certificat signé de l'autorité de certification.

   Envoyez le CSR à l'autorité de certification et obtenez le certificat signé.

   Note: Si le certificat reçu de l'AC n'est pas une chaîne de certificats contenant tous les certificats respectifs, composez tous les certificats pertinents dans un fichier de chaîne de certificats unique.

3. Déployez le certificat et la clé.

   Décrypter la clé générée précédemment dans le cadre de la première étape avec leopenssl rsa -in nginx.key -out nginx_decrypted.keyerasecat4000_flash:. Placez le certificat signé de l'autorité de certification et la clé déchiffrée dans le dossier /usr/local/openresty/nginx/ssl de la machine proxy inverse. Mettre à jour/ajouter des configurations SSL liées au certificat dans les configurations Nginx dans le fichier de configuration /usr/local/openresty/nginx/conf/conf.d/ssl/ssl.conf. 

   
   ssl_certificate /usr/local/openresty/nginx/ssl/ca_signed_cert.crt; ssl_certificate_key /usr/local/openresty/nginx/ssl/nginx_decrypted.key;

4. Configurez les autorisations pour les certificats.

   Saisissez  chmod 400 /usr/local/openresty/nginx/ssl/ca_signed_cert.crtetchmod 400 /usr/local/openresty/nginx/ssl/nginx_decrypted.key, afin que le certificat dispose d'une autorisation en lecture seule et soit limité au propriétaire.

5. Rechargez Nginx.
   
   

   Utiliser le paramètre Diffie-Hellman personnalisé

   Créez un paramètre Diffie-Hellman personnalisé avec les commandes suivantes :
   
   openssl dhparam -out /usr/local/openresty/nginx/ssl/dhparam.pem 2048 chmod 400 /usr/local/openresty/nginx/ssl/dhparam.pem
   
   
   Modifiez la configuration du serveur pour utiliser les nouveaux paramètres du fichier /usr/local/openresty/nginx/conf/conf.d/ssl/ssl.conf:
   
   ssl_dhparam /usr/local/openresty/nginx/ssl/dhparam.pem;

S'assurer que l'agrégation OCSP est activée - Vérification de révocation de certificat

Note: Afin d'activer ceci, le serveur doit utiliser un certificat signé par l'autorité de certification et le serveur doit avoir accès à l'autorité de certification qui a signé le certificat.

Ajoutez/mettez à jour cette configuration dans file/usr/local/openresty/nginx/conf/conf.d/ssl/ssl.conf:

ssl_stapling on; ssl_stapling_verify on;

Configuration Nginx

Le fichier de configuration Nginx par défaut (/usr/local/openresty/nginx/conf/nginx.conf) doit être modifié pour contenir ces entrées afin de renforcer la sécurité et d'assurer les performances. Ce contenu doit être utilisé pour modifier le fichier de configuration par défaut créé par l'installation de Nginx.

# Increasing number of worker processes will not increase the processing the request. The number of worker process will be same as number of cores
# in system CPU. Nginx provides "auto" option to automate this, which will spawn one worker for each CPU core.
worker_processes  auto;

# Process id file location
pid /usr/local/openresty/nginx/logs/nginx.pid;

# Binds each worker process to a separate CPU
worker_cpu_affinity auto;

#Defines the scheduling priority for worker processes. This should be calculated by "nice" command. In our proxy set up the value is 0
worker_priority 0;


error_log  /usr/local/openresty/nginx/logs/error.log info;

#user root root;

# current limit on the maximum number of open files by worker processes, keeping 10 times of worker_connections

worker_rlimit_nofile 102400;

events {
    multi_accept on;


    # Sets the maximum number of simultaneous connections that can be opened by a worker process.
    # This should not be more the current limit on the maximum number of open files i.e. hard limit of the maximum number of open files for the user (ulimit -Hn)
    # The appropriate setting depends on the size of the server and the nature of the traffic, and can be discovered through testing.
    worker_connections  10240;
    #debug_connection 10.78.95.21
}


http {

    include       mime.types;


    default_type  text/plain;


    ## Must-change Change with DNS resolver ip in deployment
    resolver 192.168.1.3;


    ## Must-change change lua package path to load lua libraries
    lua_package_path  "/usr/local/openresty/lualib/resty/?.lua;/usr/local/openresty/nginx/lua/?.lua;;"


    ## Must-change change proxy_temp folder as per cache directory configurations
    proxy_temp_path /usr/local/openresty/nginx/cache/proxy_temp 1 2 ;
    ## Must-change change client_temp folder as per cache directory configurations
    client_body_temp_path /usr/local/openresty/nginx/cache/client_temp 1 2 ;


    lua_shared_dict userlist 50m;
    lua_shared_dict credentialsstore 100m;
    lua_shared_dict userscount 100k;
    lua_shared_dict clientstorage 100m;
    lua_shared_dict blockingresources 100m;
    lua_shared_dict tokencache_saproxy 10M;
    lua_shared_dict tokencache_saproxy125 10M;
    lua_shared_dict ipstore 10m;
    lua_shared_dict desktopurllist 10m;
    lua_shared_dict desktopurlcount 100k;
    lua_shared_dict thirdpartygadgeturllist 10m;
    lua_shared_dict thirdpartygadgeturlcount 100k;
    lua_shared_dict corsheadersstore 100k;


    init_worker_by_lua_block {
        local UsersListManager = require('users_list_manager')
        local UnauthenticatedDesktopResourcesManager = require("unauthenticated_desktopresources_manager")
        local UnauthenticatedResourcesManager = require("unauthenticated_thirdpartyresources_manager")
        --  Must-change Replace saproxy.cisco.com with reverseproxy fqdn

        if  ngx.worker.id() == 0 then
            UsersListManager.getUserList("saproxy.cisco.com", "https://saproxy.cisco.com:8445/finesse/api/Users")
            UnauthenticatedDesktopResourcesManager.getDesktopResources("saproxy.cisco.com", "https://saproxy.cisco.com:8445/desktop/api/urls?type=desktop") 
            UnauthenticatedResourcesManager.getThirdPartyGadgetResources("saproxy.cisco.com", "https://saproxy.cisco.com:8445/desktop/api/urls?type=3rdParty")
        end 
    }

    include conf.d/*.conf;

    sendfile        on;

    tcp_nopush     on;

    server_names_hash_bucket_size 512;

Configurer le port proxy inverse

Par défaut, la configuration Nginx écoute les requêtes Finesse sur le port 8445. À la fois, un seul port peut être activé à partir d'un proxy inverse pour prendre en charge les requêtes Finesse, par exemple 8445. Si le port 443 doit être pris en charge, modifiez le fichier <nginx-install-directory>conf/conf.d/finesse.conf afin d'activer l'écoute sur 443 et de désactiver l'écoute sur 8445.

Configuration de l'authentification mutuelle TLS entre les composants de proxy inverse et en amont

L'authentification du certificat SSL client pour les connexions à partir d'hôtes proxy inverse peut être activée sur les composants en amont de CCBU CUIC/Finesse/IdS/Livedata via une nouvelle option CLI CVOS qui est

utils system inverproxy client-auth enable/disable/status.

Par défaut, cette option est désactivée et doit être explicitement activée par l'administrateur en exécutant l'interface de ligne de commande sur chaque serveur en amont indépendamment. Une fois cette option activée, le service proxy Web Cisco exécuté sur l'hôte en amont commence à authentifier les certificats clients dans la connexion TLS pour les connexions provenant d'hôtes de proxy inverse approuvés ajoutés dans le cadre de l'interface de ligne de commande utils system inverproxy allowed-hosts add <proxy-host>.

Ci-dessous se trouve le bloc de configuration pour le même dans les fichiers de configuration proxy, à savoir ssl.conf et ssl2.conf.

#Must-change /usr/local/openresty/nginx/ssl/nginx.crt change this location accordingly proxy_ssl_certificate /usr/local/openresty/nginx/ssl/nginx.crt; #Must-change /usr/local/openresty/nginx/ssl/nginx.key change this location accordingly proxy_ssl_certificate_key /usr/local/openresty/nginx/ssl/nginx.key;

Le certificat SSL utilisé pour le trafic sortant (proxy vers amont) peut être identique au certificat ssl configuré pour le trafic entrant (connecteur SSL pour les blocs de serveurs de composants). Si le certificat auto-signé est utilisé comme proxy_ssl_certificate qu'il doit être téléchargé vers les composants en amont (Finesse/IdS/CUIC/Livedata) du magasin de confiance pour qu'il soit authentifié avec succès.

La validation du certificat du serveur en amont par proxy inverse est facultative et désactivée par défaut. Si vous souhaitez réaliser une authentification mutuelle TLS complète entre les hôtes proxy inverses et les hôtes en amont, la configuration ci-dessous doit être déscommentée à partir des fichiers ssl.conf et ssl2.conf.

#Enforce upstream server certificate validation at proxy -> #this is not mandated as per CIS buit definitely adds to security. #It requires the administrator to upload all upstream server certificates to the proxy certificate store #Must-Change Uncomment below lines IF need to enforce upstream server certificate validation at proxy #proxy_ssl_verify on; #proxy_ssl_trusted_certificate /usr/local/openresty/nginx/ssl/finesse25.crt; proxy_ssl_trusted_certificate: This file should contain the all upstream certificate enteries concatenated together

Cavates pour configurer l'authentification TLS mutuelle :

• Une fois cette fonctionnalité activée sur le certificat du client des composants CCBU, les clients LAN seront également invités lors de la connexion TLS. Dans le cas où des certificats client/personnel sont installés sur des navigateurs de machine client, vous pouvez choisir d'afficher une fenêtre contextuelle pour demander à l'utilisateur final de choisir le certificat approprié pour l'authentification client. Bien que peu importe le certificat que l'utilisateur final choisit ou appuie sur annuler sur les requêtes contextuelles réussira, car l'authentification du certificat client n'est pas appliquée aux clients LAN, mais le changement d'expérience sera là. Référez-vous à CDET CSCwa26057 pour plus de détails.
• Le service proxy Web des composants en amont ne s'affiche pas si un hôte proxy est ajouté à la liste autorisée qui n'est pas résolvable par le service proxy Web. Assurez-vous que les hôtes de proxy inverse ajoutés à la liste autorisée peuvent être résolus à partir du composant en amont via la recherche DNS.
  
  

Effacer le cache

Le cache de proxy inverse peut être effacé avec /clearCache.sh erasecat4000_flash:.

Directives standard

Cette section décrit brièvement les instructions standard à suivre lors de la configuration de Nginx en tant que serveur proxy.

Ces directives proviennent du Centre pour la sécurité sur Internet. Pour plus de détails sur chaque ligne directrice, reportez-vous à la même section.

1. Il est toujours recommandé d'utiliser la dernière version stable d'OpenResty et d'OpenSSL.
2. Il est conseillé d'installer Nginx sur un disque séparé.
3. L'ID de processus Nginx doit être la propriété de l'utilisateur racine (ou selon le cas pour le système d'exploitation choisi) et doit avoir l'autorisation 644 (rw—) ou plus stricte.
4. Nginx doit bloquer les requêtes pour les hôtes inconnus. Assurez-vous que chaque bloc de serveur contient la directive server_name explicitement définie. Afin de vérifier, recherchez tous les blocs de serveur dans le répertoire nginx.conf et nginx/conf.d et vérifiez que tous les blocs de serveur contiennent le nom_serveur.
5. Nginx doit écouter uniquement sur les ports autorisés. Recherchez tous les blocs de serveur dans le répertoire nginx.conf et nginx/conf.d et recherchez les directives d'écoute afin de vérifier que seuls les ports autorisés sont ouverts à l'écoute.
6. Puisque Cisco Finesse ne prend pas en charge HTTP, est-il recommandé de bloquer également le port HTTP du serveur proxy ?
7. Le protocole SSL de Nginx doit être TLS 1.2. La prise en charge des protocoles SSL hérités doit être supprimée. Il doit également désactiver les chiffrements SSL faibles.
8. Il est conseillé d'envoyer les journaux d'accès et d'erreur Nginx au serveur Syslog distant.
9. Il est conseillé d'installer le module mod_security qui fonctionne comme un pare-feu d'application Web. Pour plus d'informations, reportez-vous au manuel ModSecurity. Notez que la charge Nginx n'a pas été vérifiée dans le module mod_security en place.

Configurer le fichier de mappage

Le déploiement du proxy inverse du bureau Finesse nécessite un fichier de mappage pour configurer la liste des combinaisons nom d'hôte/port visibles de l'extérieur et leur mappage aux noms de serveurs et ports réels qui sont utilisés par les serveurs Finesse, IdS et CUIC. Ce fichier de mappage qui est configuré sur les serveurs internes est la configuration clé qui permet aux clients connectés via Internet d'être redirigés vers les hôtes et ports requis qui sont utilisés sur Internet.

Le fichier de mappage doit être déployé sur un serveur Web accessible aux serveurs de composants et son URI doit être configuré pour que le déploiement fonctionne. Il est recommandé de configurer le fichier de mappage à l'aide d'un serveur Web dédié disponible sur le réseau. Si un tel serveur n'est pas disponible, le proxy inverse peut être utilisé à la place, ce qui exigera que le proxy soit accessible à partir du réseau et présente également un risque d'exposition des informations aux clients externes qui peuvent effectuer un accès non autorisé à la zone démilitarisée. La section suivante décrit comment cela peut être fait.

Reportez-vous au guide des fonctionnalités pour connaître les étapes exactes de configuration de l'URI du fichier de mappage sur tous les serveurs de composants et pour plus d'informations sur la création des données du fichier de mappage.

Utiliser Reverse Proxy comme serveur de fichiers de mappage

Ces étapes ne sont requises que si le proxy inverse est également utilisé comme hôte de fichier de mappage de proxy.

1. Configurez le nom d'hôte de proxy inverse dans le contrôleur de domaine utilisé par les hôtes Finesse/CUIC et IdS de sorte que son adresse IP puisse être résolue.
2. Téléchargez les certificats signés Nginx générés sur les deux noeuds sous tomcat-trust de cmplatform et redémarrez le serveur.
3. Mettez à jour les valeurs à modifier dans <NGINX_HOME>/html/proxymap.txt.
4. Rechargez les configurations Nginx avec nginx -s reload erasecat4000_flash:.
5. Valider que le fichier de configuration est accessible depuis un autre hôte réseau à l’aide de curl erasecat4000_flash:.

Durcissement du noyau CentOS 8

Si le système d'exploitation choisi est CentOS 8, il est recommandé que le durcissement/réglage du noyau soit effectué avec l'utilisation de ces configurations sysctl pour les installations qui utilisent un serveur dédié pour héberger le proxy.

## Configurations for kernel hardening - CentOS8. The file path is /etc/sysctl.conf
## Note that the commented configurations denote that CentOS 8's default value matches
## the recommended/tested value, and are not security related configurations.

# Avoid a smurf attack
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Turn on protection for bad icmp error messages
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Turn on syncookies for SYN flood attack protection
net.ipv4.tcp_syncookies = 1

# Turn on and log spoofed, source routed, and redirect packets
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

# Turn off routing
net.ipv4.ip_forward = 0
net.ipv4.conf.all.forwarding = 0
net.ipv6.conf.all.forwarding = 0

net.ipv4.conf.all.mc_forwarding = 0
net.ipv6.conf.all.mc_forwarding = 0

# Block routed packets
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# Block ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Filter routing packets with inward-outward path mismatch(reverse path filtering)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Router solicitations & advertisements related.
net.ipv6.conf.default.router_solicitations = 0
net.ipv6.conf.default.accept_ra_rtr_pref = 0
net.ipv6.conf.default.accept_ra_pinfo = 0
net.ipv6.conf.default.accept_ra_defrtr = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.dad_transmits = 0
net.ipv6.conf.default.max_addresses = 1
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0

# Backlog - increased from default 1000 to 5000.
net.core.netdev_max_backlog = 5000

# Setting syn/syn-ack retries to zero, so that they don't stay in the queue.
net.ipv4.tcp_syn_retries = 0
net.ipv4.tcp_synack_retries = 0

# Max tcp listen backlog. Setting it to 511 to match nginx config
net.core.somaxconn = 511

# Reduce the duration of connections held in TIME_WAIT(seconds)
net.ipv4.tcp_fin_timeout = 6

# Maximum resources allotted
# fs.file-max = 2019273
# kernel.pid_max = 4194304
# net.ipv4.ip_local_port_range = 32768 60999

# TCP window size tuning
# net.ipv4.tcp_window_scaling = 1
# net.core.rmem_default = 212992
# net.core.rmem_max = 212992
# net.ipv4.tcp_rmem = 4096 87380 6291456
# net.ipv4.udp_rmem_min = 4096
# net.core.wmem_default = 212992
# net.core.wmem_max = 212992
# net.ipv4.tcp_wmem = 4096 16384 4194304
# net.ipv4.udp_wmem_min = 4096
# vm.lowmem_reserve_ratio = 256 256 32 0 0
# net.ipv4.tcp_mem = 236373 315167 472746

# Randomize virtual address space
kernel.randomize_va_space = 2

# Congestion control
# net.core.default_qdisc = fq_codel
# net.ipv4.tcp_congestion_control = cubic

# Disable SysReq
kernel.sysrq = 0

# Controls the maximum size of a message, in bytes
kernel.msgmnb = 65536

# Controls the default maximum size of a message queue
kernel.msgmax = 65536

# Controls the eagerness of the kernel to swap.
vm.swappiness = 1

Un redémarrage est recommandé après avoir effectué les modifications recommandées.

Durcissement des tables IP

IPtables est une application qui permet à un administrateur système de configurer les tables, chaînes et règles IPv4 et IPv6 fournies par le pare-feu du noyau Linux.

Ces règles IPtables sont configurées pour sécuriser l'application proxy contre les attaques en force en limitant l'accès dans le pare-feu du noyau Linux.

Les commentaires de la configuration indiquent quel service est limité à la vitesse à l'aide des règles.

Note: Si les administrateurs utilisent un port différent ou étendent l'accès à plusieurs serveurs utilisant les mêmes ports, le dimensionnement approprié doit être effectué pour ces ports en fonction de ces numéros.

## Configuration for iptables service
## The file path is /etc/sysconfig/iptables
## Make a note for must-change values to be replaced.
## Restart of the iptable service is required after applying following rules

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

# Ensure loopback traffic is configured
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT -s 127.0.0.0/8 -j DROP

# Ensure ping openeded only for the particular source and blocked for rest
# Must-Change: Replace the x.x.x.x with valid ip address
-A INPUT -p ICMP --icmp-type 8 -s x.x.x.x -j ACCEPT

# Ensure outbound and established connections are configured
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

# Block ssh for external interface
# Must-Change: Replace the ens224 with valid ethernet interface
-A INPUT -p tcp -i ens224 --dport 22 -j DROP
# Open inbound ssh(tcp port 22) connections
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT


# Configuration for finesse 8445 port
-A INPUT -p tcp -m tcp --dport 8445 --tcp-flags SYN SYN -m connlimit --connlimit-above 10 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Connections to 8445 exceeded connlimit "
-A INPUT -p tcp -m tcp --dport 8445 --tcp-flags SYN SYN -m connlimit --connlimit-above 10 --connlimit-mask 32 --connlimit-saddr -j DROP
 -A INPUT -p tcp -m tcp --dport 8445 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 6/sec --hashlimit-burst 8 --hashlimit-mode srcip,dstport --hashlimit-name TCP_8445_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8445 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 8445 hashlimit "
-A INPUT -p tcp -m tcp --dport 8445 --tcp-flags SYN SYN -j DROP

# Configuration for IdS 8553 port
-A INPUT -p tcp -m tcp --dport 8553 --tcp-flags SYN SYN -m connlimit --connlimit-above 6 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " IdS connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 8553 --tcp-flags SYN SYN -m connlimit --connlimit-above 6 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 8553 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 2/sec --hashlimit-burst 4 --hashlimit-mode srcip,dstport --hashlimit-name TCP_8553_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8553 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 8553 hashlimit "
-A INPUT -p tcp -m tcp --dport 8553 --tcp-flags SYN SYN -j DROP

# Configuration for IdP 443 port
-A INPUT -p tcp -m tcp --dport 443 --tcp-flags SYN SYN -m connlimit --connlimit-above 8 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " IdP connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 443 --tcp-flags SYN SYN -m connlimit --connlimit-above 8 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 443 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 4/sec --hashlimit-burst 6 --hashlimit-mode srcip,dstport --hashlimit-name TCP_443_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 443 hashlimit "
-A INPUT -p tcp -m tcp --dport 443 --tcp-flags SYN SYN -j DROP


# Must-Change: A2A file transfer has not been considered for below IMNP configuration. 
# For A2A for support, these configuration must be recalculated to cater different file transfer scenarios.

# Configuration for IMNP 5280 port
-A INPUT -p tcp -m tcp --dport 5280 --tcp-flags SYN SYN -m connlimit --connlimit-above 30 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " IMNP connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 5280 --tcp-flags SYN SYN -m connlimit --connlimit-above 30 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 5280 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 20/sec --hashlimit-burst 25 --hashlimit-mode srcip,dstport --hashlimit-name TCP_5280_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5280 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 5280 hashlimit "
-A INPUT -p tcp -m tcp --dport 5280 --tcp-flags SYN SYN -j DROP

# Configuration for IMNP 15280 port
-A INPUT -p tcp -m tcp --dport 15280 --tcp-flags SYN SYN -m connlimit --connlimit-above 30 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " IMNP connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 15280 --tcp-flags SYN SYN -m connlimit --connlimit-above 30 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 15280 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 20/sec --hashlimit-burst 25 --hashlimit-mode srcip,dstport --hashlimit-name TCP_15280_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 15280 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 15280 hashlimit "
-A INPUT -p tcp -m tcp --dport 15280 --tcp-flags SYN SYN -j DROP


# Configuration for IMNP 25280 port
-A INPUT -p tcp -m tcp --dport 25280 --tcp-flags SYN SYN -m connlimit --connlimit-above 30 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " IMNP connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 25280 --tcp-flags SYN SYN -m connlimit --connlimit-above 30 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 25280 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 20/sec --hashlimit-burst 25 --hashlimit-mode srcip,dstport --hashlimit-name TCP_25280_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25280 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 25280 hashlimit "
-A INPUT -p tcp -m tcp --dport 25280 --tcp-flags SYN SYN -j DROP


# Configuration for CUIC 8444 port
-A INPUT -p tcp -m tcp --dport 8444 --tcp-flags SYN SYN -m connlimit --connlimit-above 6 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " CUIC connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 8444 --tcp-flags SYN SYN -m connlimit --connlimit-above 6 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 8444 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 2/sec --hashlimit-burst 4 --hashlimit-mode srcip,dstport --hashlimit-name TCP_8444_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8444 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 8444 hashlimit "
-A INPUT -p tcp -m tcp --dport 8444 --tcp-flags SYN SYN -j DROP

# Configuration for CUIC 8447 port
-A INPUT -p tcp -m tcp --dport 8447 --tcp-flags SYN SYN -m connlimit --connlimit-above 6 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " CUIC connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 8447 --tcp-flags SYN SYN -m connlimit --connlimit-above 6 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 8447 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 2/sec --hashlimit-burst 4 --hashlimit-mode srcip,dstport --hashlimit-name  TCP_8447_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8447 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 8447 hashlimit "
-A INPUT -p tcp -m tcp --dport 8447 --tcp-flags SYN SYN -j DROP

# Configuration for LiveData 12005  port
-A INPUT -p tcp -m tcp --dport 12005 --tcp-flags SYN SYN -m connlimit --connlimit-above 10 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " LD connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 12005 --tcp-flags SYN SYN -m connlimit --connlimit-above 10 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 12005 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 6/sec --hashlimit-burst 8 --hashlimit-mode srcip,dstport --hashlimit-name TCP_12005_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 12005 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 12005 hashlimit "
-A INPUT -p tcp -m tcp --dport 12005 --tcp-flags SYN SYN -j DROP

# Configuration for LiveData 12008  port
-A INPUT -p tcp -m tcp --dport 12008 --tcp-flags SYN SYN -m connlimit --connlimit-above 10 --connlimit-mask 32 --connlimit-saddr -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " LD connection limit exceeded"
-A INPUT -p tcp -m tcp --dport 12008 --tcp-flags SYN SYN -m connlimit --connlimit-above 10 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -p tcp -m tcp --dport 12008 --tcp-flags SYN SYN -m hashlimit --hashlimit-upto 6/sec --hashlimit-burst 8 --hashlimit-mode srcip,dstport --hashlimit-name  TCP_12008_DOS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 12008 --tcp-flags SYN SYN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix " Exceeded 12008 hashlimit "
-A INPUT -p tcp -m tcp --dport 12008 --tcp-flags SYN SYN -j DROP

# Block all other ports
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

COMMIT

Ces règles peuvent être appliquées directement en éditant le fichier /etc/sysconfig/iptables manuellement ou en sauvegardant la configuration dans un fichier tel que iptables.conf et en exécutant cat iptables.conf »/etc/sysconfig/iptables pour appliquer les règles.

Un redémarrage du service IPtables est nécessaire après l'application des règles. Saisissez  systemctl restart iptables afin de redémarrer le service IPtables.

Restreindre les connexions client

En plus de la configuration précédente des tables IP, les installations qui connaissent la plage d'adresses des clients qui utilisent le proxy sont recommandées pour utiliser ces connaissances pour sécuriser les règles d'accès au proxy. Cela peut générer d'énormes profits lorsqu'il s'agit de sécuriser le proxy à partir de botnets de réseaux malveillants qui sont souvent créés dans la gamme d'adresses IP de pays qui ont des règles plus laxistes en matière de sécurité en ligne. Il est donc fortement recommandé de limiter les plages d'adresses IP aux plages d'adresses de pays/état ou d'adresses IP basées sur le FAI si vous êtes sûr des modèles d'accès.

Bloquer les connexions client

Il est également utile de savoir comment bloquer une plage spécifique d’adresses lorsqu’une attaque est identifiée à partir d’une adresse IP ou d’une plage d’adresses IP. Dans de tels cas, les requêtes de ces adresses IP peuvent être bloquées avec des règles iptable.

Bloquer les adresses IP distinctes

Afin de bloquer plusieurs adresses IP distinctes, ajoutez une ligne au fichier de configuration IPTables pour chaque adresse IP.

Par exemple, pour bloquer les adresses 192.0.2.3 et 192.0.2.4, saisissez :

iptables -A INPUT -s 192.0.2.3 -j DROP iptables -A INPUT -s 192.0.2.4 - j DROP.

Bloquer une plage d’adresses IP

Bloquez plusieurs adresses IP dans une plage et ajoutez une seule ligne au fichier de configuration IPTables avec la plage IP.

Par exemple, pour bloquer les adresses de 192.0.2.3 à 192.0.2.35, saisissez :

iptables -A INPUT -m iprange --src-range 192.0.2.3-192.0.2.35 -j DROP.

Bloquer toutes les adresses IP dans un sous-réseau

Bloquez toutes les adresses IP d'un sous-réseau entier en ajoutant une seule ligne au fichier de configuration IPTables avec l'utilisation de la notation de routage inter-domaine sans classe pour la plage d'adresses IP. Par exemple, pour bloquer toutes les adresses de classe C, saisissez :

iptables -A INPUT -s 192.0.0.0/16 -j DROP.

SELinux

SELinux est un framework de sécurité de plate-forme intégré comme une amélioration dans le système d'exploitation Linux. La procédure d'installation et d'ajout de stratégies SELinux pour exécuter OpenResty lorsque le proxy inverse est fourni ensuite.

1. Arrêter le processus à l'aide de openresty -s stop erasecat4000_flash:.
2. Configurez et démarrez le serveur nginx avec systemctl pour que, lors du démarrage, le processus OpenResty démarre automatiquement. Entrez ces commandes en tant qu'utilisateur racine.
   1. Accédez à /usr/lib/systemd/system.
   2. Ouvrir le fichier appelé openresty.service.
   3. Mettre à jour le contenu du fichier conformément à l'emplacement PIDFile.

      [Unit]
      Description=The OpenResty Application Platform
      After=syslog.target network-online.target remote-fs.target nss-lookup.target
      Wants=network-online.target
       
      [Service]
      Type=forking
      PIDFile=/usr/local/openresty/nginx/logs/nginx.pid
      ExecStartPre=/usr/local/openresty/nginx/sbin/nginx -t
      ExecStart=/usr/local/openresty/nginx/sbin/nginx
      ExecReload=/bin/kill -s HUP $MAINPID
      ExecStop=/bin/kill -s QUIT $MAINPID
      PrivateTmp=true
       
      [Install]
      WantedBy=multi-user.target

   4. En tant qu'utilisateur root, saisissez sudo systemctl enable openresty.
   5. Démarrez/arrêtez le service OpenResty à l'aide de la commande systemctl start openresty / systemctl stop openresty et assurez-vous que le processus démarre / s'arrête en tant qu'utilisateur root.

1. Installer Selinux
   • Par défaut, seuls certains paquets SELinux seront installés dans CentOs.

   • Le package policy coreutils-devel et ses dépendances doivent être installés afin de générer la stratégie SELinux.

   • Entrez cette commande afin d'installer policy coreutils-devel

     yum install policycoreutils-devel

   • Assurez-vous qu'après avoir installé le package, sepolicy fonctionne.

     usage: sepolicy [-h] [-P POLICY]
                       
                     {booleans,communicate,generate,gui,interface,manpage,network,transition}
                     ...
       
     SELinux Policy Inspection Tool

2. Créer un nouvel utilisateur et une nouvelle carte Linux avec SElinux User

   1. Saisissez  semanage login -l afin d'afficher le mappage entre les utilisateurs Linux et SELinux.

      [root@loadproxy-cisco-com ~]# semanage login -l
        
      Login Name           SELinux User         MLS/MCS Range        Service
        
      __default__          unconfined_u         s0-s0:c0.c1023       *               *
      root                 unconfined_u         s0-s0:c0.c1023       *

   2. En tant que root, créez un nouvel utilisateur Linux (utilisateur nginx) mappé à l'utilisateur utilisateur SELinux.

      useradd -Z user_u nginxuser
      [root@loadproxy-cisco-com ~]# passwd nginxuser
      Changing password for user nginxuser.
      New password:
      Retype new password:
      passwd: all authentication tokens updated successfully.

   3. Afin d'afficher le mappage entre nginxuser et user_u, entrez cette commande en tant que root :

      [root@loadproxy-cisco-com ~]# semanage login -l
        
      Login Name           SELinux User         MLS/MCS Range        Service
        
      __default__          unconfined_u         s0-s0:c0.c1023       *
      nginxuser            user_u               s0                   *
      root                 unconfined_u         s0-s0:c0.c1023       *

   4. SELinux __default__ login par défaut mappé à l'utilisateur SELinux unlimited_u. Il est nécessaire que user_u soit confiné par défaut avec cette commande :

      semanage login -m -s user_u -r s0 __default__

      Afin de vérifier si la commande fonctionne correctement, entrez semanage login -l. Il doit produire ce résultat :

      

   5. Modifiez nginx.conf et modifiez la propriété de nginxuser.

      1. Saisissez  chown -R nginxuser:nginxuser * dans le répertoire <Openresty-install-directory>.

      2. Modifiez le fichier nginx.conf pour inclure nginxuser comme utilisateur pour l'exécution des processus de travail.

         ........
           
         user nginxuser nginxuser;
           
         ..........

Écrire la stratégie SELinux pour Nginx

1. Au lieu de générer une nouvelle stratégie personnalisée par défaut pour Nginx avec sepolicy generate --init /usr/bin/nginx , il est préférable de commencer par une stratégie existante.
2. Les fichiers nginx.fc (fichier de contexte de fichier) et nginx.te (fichier d'application de type) téléchargés à partir de l'URL fournie ont été modifiés pour s'adapter à l'utilisation du proxy inverse.
3. Cette version modifiée peut être utilisée comme référence car elle a été corrigée pour le cas d'utilisation particulier.
4. Téléchargez le fichier selinux-nginx-rhel-master-modified.tar à partir de la page de téléchargement du logiciel de fichier.

   

5. Extrayez le fichier .tar et naviguez jusqu'au répertoire nginx qui s'y trouve.
6. Ouvrez le fichier .fc et vérifiez les chemins d'accès requis du programme d'installation, du cache et du fichier pid de nginx.
7. Compilez la configuration à l'aide de la commande make erasecat4000_flash:.
8. Le fichier nginx.pp sera généré.
9. Charger la stratégie à l'aide de semodule erasecat4000_flash:.

   semodule -i nginx.pp

10. Accédez à /root et créez un fichier vide appelé touch /.autorelabel.
11. Redémarrez le système.
12. Entrez cette commande afin de vérifier que la stratégie a bien été chargée.

    semodule --list-modules=full

    

13. Nginx doit fonctionner sans aucune violation. (Les violations seront disponibles dans /var/log/messages et /var/log/audit/audit.log).
14. Entrez cette commande afin de vérifier l'état de Nginx.

    ps -aefZ | grep nginx

    

15. Le bureau de superviseur/agent Finesse doit maintenant être accessible.

Vérification

Utilisez cette section pour confirmer que votre configuration fonctionne correctement.

Finesse

1. Demandez https://<inverseproxy:port>/finesse/api/SystemInfo. à partir de la zone DMZ et vérifiez qu'ils sont accessibles.
2. Les valeurs <host> dans <primaryNode> et <secondaryNode> sont des noms d'hôte de proxy inverse valides. Il ne doit pas s'agir de noms d'hôte Finesse.

CUIC et données en direct

1. Si les noms d'hôte Finesse sont affichés dans la réponse au lieu des noms d'hôte de proxy inversés, validez les configurations de mappage de proxy et les hôtes autorisés sont correctement ajoutés dans les serveurs Finesse comme décrit dans la section « Remplir les données de traduction de réseau » de « VPN-less Access to Finesse Desktop » dans le Guide de fonctionnalités UCCE Finesse 12.6.
2. Si les gadgets LiveData se chargent correctement dans Finesse Desktop, les configurations de proxy CUIC et LiveData sont appropriées.
3. Afin de valider la configuration CUIC et LiveData, envoyez des requêtes HTTP à ces URL à partir de la DMZ et voyez si elles sont accessibles.
   • https://<inverseproxy:port_cuic>/cuic/rest/à propos de
   • https://<inverseproxy:ldweb_port>/livedata/security
   • https://<inverseproxy:ldsocketio_port>/sécurité

IdS

Afin de valider la configuration d'IDS, procédez comme suit :

1. Connectez-vous à l'interface IdSAdmin à l'adresse https://<ids_LAN_host:ids_port>:8553/idsadmin à partir du réseau local, car l'interface d'administration n'est pas exposée sur le proxy inverse.
2. Sélectionnez Paramètres > Approbation IdS.
3. Vérifiez que le noeud éditeur du cluster proxy est répertorié sur la page Télécharger les métadonnées du SP et cliquez sur Suivant.
4. Vérifiez que le proxy IDP est correctement affiché si configuré sur la page de métadonnées Upload IDP, puis cliquez sur Suivant.
5. Lancez le test SSO via tous les noeuds de cluster proxy à partir de la page Test SSO et validez que tous ont réussi. Cela nécessite la connectivité de la machine cliente pour inverser les noeuds proxy.

Performances

L'analyse des données de la capture des performances équivalentes supérieures, réalisée avec l'outil nmon, est disponible à partir de la page de téléchargement du logiciel ES03 de Finesse version 12.6(1) (load_result.zip). Les données représentent l'état du proxy pour les opérations de bureau et de superviseur, sur un exemple de déploiement UCCE 2000 à l'aide de connexions SSO et de rapports UCCE LD CUIC configurés dans la disposition par défaut pour 2000 utilisateurs pour une période de huit heures. Il peut être utilisé pour calculer les besoins en matière de calcul, de disque et de réseau pour une installation utilisant Nginx sur un matériel comparable.

ssl_stapling on;
ssl_stapling_verify on;

Dépannage

SELinux

1. Si Nginx n'est pas démarré par défaut ou si le bureau de l'agent Finesse n'est pas accessible, définissez SELinux sur le mode autorisé avec cette commande :

   setenforce 0

2. Essayez de redémarrer le Nginx avec le systemctl restart nginx erasecat4000_flash:.
3. Les violations seront disponibles dans /var/log/messages et /var/log/audit/audit.log.
4. Il est nécessaire de régénérer le fichier .te avec des règles d'autorisation pour traiter ces violations par l'une de ces commandes :

   cat /var/log/audit/audit.log | audit2allow -m nginx1 > nginx1.te. # this will create nginx1.te file
                   or
   ausearch -c 'nginx' --raw | audit2allow -M  my-nginx  # this will create my-nginx.te file

5. Mettez à jour le fichier nginx.te d'origine présent dans le répertoire selinux-nginx-rhel-master-modified/nginx avec les règles d'autorisation nouvellement générées.
6. Compilez la même avec make erasecat4000_flash:.
7. Le fichier nginx.pp sera régénéré.
8. Chargez la stratégie par la commande semodule.

   semodule -i nginx.pp

9. Faites de SELinux le mode d'application avec cette commande :

   setenforce

10. Redémarrez le système.
11. Répétez cette procédure jusqu'à ce que les violations requises soient corrigées.