Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
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.
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.
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.
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.
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.
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.
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.
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; }
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.
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 :
yum update && yum install epel-release
yum install fail2ban
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 :
cd /etc/fail2ban
cp jail.conf jail.local
# 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
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 :
touch filter.d/finesseban.conf
[Definition]
# The regex match that would cause blocking of the host.
failregex = <HOST> will be blocked for
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.
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.
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.
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.
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.
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.
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 :
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.
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
openresty
.openresty -s stop
.La configuration est expliquée pour une installation Nginx basée sur OpenResty. Les répertoires par défaut pour OpenResty sont les suivants :
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.
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.
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.
mount -av
.df -h
erasecat4000_flash:.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;
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.
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).
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>)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>)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.
Un certificat signé par une autorité de certification peut être installé sur le proxy inverse en procédant comme suit :
Afin de générer la CSR et la clé privée, saisissezopenssl req -new -newkey rsa:4096 -keyout nginx.key -out nginx.csr
aprè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.
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.
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.key
erasecat4000_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;
Saisissez chmod 400 /usr/local/openresty/nginx/ssl/ca_signed_cert.crt
etchmod 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.
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;
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;
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;
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.
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 :
Le cache de proxy inverse peut être effacé avec
erasecat4000_flash:.
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.
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.
Ces étapes ne sont requises que si le proxy inverse est également utilisé comme hôte de fichier de mappage de proxy.
nginx -s reload
erasecat4000_flash:.curl
erasecat4000_flash:.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.
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.
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.
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.
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.
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.
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 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.
openresty -s stop
erasecat4000_flash:.systemctl
pour que, lors du démarrage, le processus OpenResty démarre automatiquement. Entrez ces commandes en tant qu'utilisateur racine.
[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
sudo systemctl enable openresty
.systemctl start openresty / systemctl stop openresty
et assurez-vous que le processus démarre / s'arrête en tant qu'utilisateur root.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
sepolicy
fonctionne. usage: sepolicy [-h] [-P POLICY] {booleans,communicate,generate,gui,interface,manpage,network,transition} ... SELinux Policy Inspection Tool
Créer un nouvel utilisateur et une nouvelle carte Linux avec SElinux User
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 *
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.
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 *
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 :
Modifiez nginx.conf et modifiez la propriété de nginxuser.
chown -R nginxuser:nginxuser
* dans le répertoire <Openresty-install-directory>.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
sepolicy generate --init /usr/bin/nginx
, il est préférable de commencer par une stratégie existante.make
erasecat4000_flash:.semodule
erasecat4000_flash:. semodule -i nginx.pp
semodule --list-modules=full
ps -aefZ | grep nginx
Utilisez cette section pour confirmer que votre configuration fonctionne correctement.
Afin de valider la configuration d'IDS, procédez comme suit :
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;
SELinux
setenforce 0
systemctl restart nginx
erasecat4000_flash:.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
make
erasecat4000_flash:.semodule -i nginx.pp
setenforce
Révision | Date de publication | Commentaires |
---|---|---|
5.0 |
24-Dec-2021 |
Étapes corrigées pour OpenResty. Modifiez les étapes de génération et d'application du certificat SSL. Mise à jour du document avec des liens ES03. |
4.0 |
10-Dec-2021 |
Mises à jour ES03. |
3.0 |
10-Nov-2021 |
Mise à jour des guides de solution et de la description de l'authentification. |
2.0 |
09-Nov-2021 |
Version initiale |
1.0 |
09-Nov-2021 |
Première publication |