Paramètres globaux #

Le profil HTTP gère la commutation de contenu au niveau de la couche application du modèle OSI pour les protocoles HTTP et HTTPS. Ce profil est conçu pour répartir intelligemment le trafic Web entrant sur plusieurs ressources backend en analysant le contenu des requêtes entrantes et en prenant des décisions de routage basées sur des paramètres tels que l'URL, les cookies, les en-têtes et les informations de session. À l’aide de ces informations, il dirige le trafic vers les pools de serveurs appropriés.

Dans la partie supérieure droite, nous avons 2 indicateurs. Action boutons et .
Boîte carrée : Lorsque vous cliquez dessus, la ferme LSLB s'arrête.
Bouton Actualiser: Lorsque vous cliquez dessus, la ferme redémarre.
Bouton Play: Si la ferme est éteinte ou inactive, elle démarrera lorsque vous cliquerez dessus.

Chacune des couleurs décrites ci-dessous représente le d'un donné Ferme:
Vert: Signifie que la ferme est UP et tous les backends fonctionnent. Cela peut également signifier qu'une redirection est configurée.
Rouge: Signifie que la ferme est BAS ou il n'est pas fonctionnel.
Noir: Indique une CRITIQUE dommage. Se produit généralement lorsqu'une batterie de serveurs est UP mais qu'il n'y a pas de backend disponible, ou qu'elle peut être en mode maintenance.
Bleu: S'affiche lorsqu'il y a un PROBLÈME. La batterie de serveurs peut être en cours d'exécution, mais lorsqu'au moins un backend est en panne.
Orange: Représente Entretien. S'affiche lorsque la batterie de serveurs est en cours d'exécution mais qu'au moins un backend est en mode maintenance.

Ces codes couleur sont cohérents dans toute l’interface utilisateur graphique. Pour une explication concise, reportez-vous au Section Ferme LSLB.

Dans le profil des batteries HTTP (S), l'en-tête HTTP X-Forwarded-For est automatiquement renseigné avec l'adresse IP du client.

En tant que proxy inverse, chaque batterie HTTP(S) (ou service virtuel) gère plusieurs services. Cela signifie qu'une adresse IP virtuelle HTTP et une paire de ports peuvent gérer plusieurs services Web à charge équilibrée. Par conséquent, au sein de la ferme HTTP, il existe un service section qui offre une flexibilité d’hôte virtuel et permet la création de listes backend pour chaque service.

Chaque service HTTP(S) utilise expressions régulières (pour l'hôte virtuel et le modèle d'URL) dans PCRE pour identifier des modèles spécifiques dans les en-têtes HTTP des connexions entrantes. Si un modèle correspond à la fois dans hôte virtuel et Modèle d'URL champs, les backends de ce service particulier traiteront ces connexions entrantes.

Configuration de base #

Voici les paramètres de base du profil de batterie HTTP/S.

Nom. C'est un nom qui identifie facilement une ferme. Pour changer le nom d'une ferme donnée, vous devez d'abord l'arrêter. Assurez-vous qu'un nouveau nom n'est pas déjà utilisé.

IP virtuel et port. Il s'agit des adresses IP virtuelles et des paires de ports à partir desquelles la batterie écoutera les connexions entrantes. La nouvelle combinaison d'adresse IP et de port doit être inutilisée et disponible avant d'être configurée.

Auditeur. Ce champ spécifie le protocole de couche 7 pour effectuer la commutation de contenu.

• HTTP. Le service virtuel ne recevra que du contenu HTTP brut.
• HTTPS. Le service virtuel recevra le contenu HTTP sécurisé, gérera les poignées de main SSL, gérera les configurations de chiffrement sécurisé, les certificats SSL (wildcard ou SNI), etc., pour effectuer le déchargement SSL. Cela soulagera les vrais serveurs d'applications de ces lourdes tâches.

Paramètres HTTPS #

Paramètres HTTPS Vous trouverez ci-dessous.

Désactiver SSLv2, Désactiver SSLv3, Désactiver TLSv1, Désactiver TLSv1.1, Désactiver TLSv1.2. Chacun de ces boutons bascule active ou désactive la version SSL ou TLS associée. La désactivation de l'un des protocoles n'est pas recommandée car ses chiffrements associés seront également désactivés. TLSv1.3 est activé par défaut.

chiffrements. Cette section est l'endroit où nous construisons des listes de chiffrements que nous utilisons pour renforcer une connexion SSL. Avant qu'un client et un serveur ne commencent à échanger des informations protégées par le protocole TLS, ils doivent échanger ou convenir en toute sécurité d'une clé de chiffrement et d'un chiffrement à utiliser lors du chiffrement des données.

Pour configurer un chiffrement à utiliser, sélectionnez l'une des options suivantes.

• Tous. Avec cette commande sélectionnée, la ferme HTTP(S) à l'écoute gérera toutes les suites de chiffrement disponibles. Ce sont les paramètres par défauts.
• Haute sécurité. Cette commande active les chiffrements suivants :

kEECDH+ECDSA+AES128:kEECDH+ECDSA+AES256:kEECDH+AES128:kEECDH+AES256:kEDH+AES128:kEDH+AES256:DES-CBC3-SHA:+SHA:!aNULL:!eNULL:!LOW:!kECDH:!DSS:!MD5:!EXP:!PSK:!SRP:!CAMELLIA:!SEED

L'activation de cette option offre une sécurité suffisamment forte pour passer avec un A+ grade en SSL Labs .

• Sécurité personnalisée. Cette commande vous permet de personnaliser vos propres chiffrements via le Chiffrements personnalisés champ.
• Chiffres personnalisés. Cette commande vous permet de personnaliser des chiffrements spécifiques à autoriser ou à interdire lors de l'établissement d'une connexion SSL. Il doit s'agir d'une chaîne au même format que dans Chiffres OpenSSL . Cette commande s'affichera si Sécurité personnalisée est réglé.
• Déchargement matériel SSL AES. Cette option permet aux chiffrements AES d'être déchargés via le matériel si le processeur le permet. Aes drapeau. Cela permettra d'optimiser les performances de la tâche de cryptage/déchiffrement SSL. Testez si cette option est compatible avec votre processeur actuel en exécutant la commande suivante. Si les indicateurs du processeur sont affichés, ils peuvent être utilisés.

root@noid-ee-02:~# grep "flags.* aes" /proc/cpuinfo

Certificats disponibles: Ce sont les certificats SSL installés sur l'appareil. Pour activer un certificat, sélectionnez-le et cliquez sur le bouton fléché ou faites-le glisser et déposez-le de la zone Disponible vers la zone Activé. Vous pouvez également activer/désactiver plusieurs certificats ou tous.

Certificats activés: Cette liste montre les certificats actuellement utilisés par la ferme. Vous pouvez les déplacer vers le haut ou le bas à l’aide des doubles flèches haut/bas ou les désactiver toutes. Notez l'ordre des certificats ; si un certificat générique est placé avant un certificat hôte, le caractère générique sera utilisé en premier.

paramètres avancés #

Réécrire les en-têtes d'emplacement. Si cette option est activée, la batterie de serveurs est obligée de modifier les en-têtes Location et Content-location en réponse aux clients. S'ils ont la valeur du backend lui-même ou du VIP mais avec un protocole différent, la réponse sera modifiée pour afficher l'hôte virtuel dans la requête. Si le bouton bascule, activé et comparer les backends est activé, seule l'adresse IP du backend sera comparée. Ceci est essentiel pour rediriger une requête vers un écouteur HTTPS sur le même serveur que l'écouteur HTTP. Si ce champ est configuré dans la section service, cette directive sera ignorée pour ce service.

Verbes HTTP acceptés: Ce champ précise les méthodes HTTP qui seront utilisées pour valider les requêtes des clients HTTP. Si la demande d'un client utilise une méthode non prise en charge, un message d'erreur s'affichera. Chaque verbe englobe également des méthodes supplémentaires de niveau inférieur.

• Requête HTTP standard. Requêtes HTTP standard (GET, POST, HEAD).
• + requête HTTP étendue. requêtes HTTP étendues (PUT, DELETE).
• + options HTTP verbe. requêtes HTTP étendues (PUT, DELETE).
• + verbes WebDAV standard. verbes WebDAV standard (VERROUILLER, DÉVERROUILLER, PROPFIND, PROPPATCH, RECHERCHER, MKCOL, DÉPLACER, COPIER, OPTIONS, TRACE, MKACTIVITÉ, DÉPART, FUSION, RAPPORT).
• + Verbes WebDAV des extensions MS. Extensions MS WebDAV verbes (SUBSCRIBE, UNSUBSCRIBE, NOTIFYER, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).
• + Verbes d'extensions MS RPC. Verbes d'extensions MS RPC (RPC_IN_DATA, RPC_OUT_DATA).

Ignorer 100 Continuer: Si activé, le 100 Continuer la fonctionnalité sera désactivée. Selon le protocole HTTP 1.1, cet en-tête signale que les données du formulaire ne doivent pas être envoyées avec la requête initiale. Au lieu de cela, il envoie l'en-tête au backend du serveur Web, qui répond par 100 (Continuer). Cela indique que le serveur a reçu les en-têtes de requête et que le client doit procéder à l'envoi du corps de la requête (par exemple, dans une requête POST). Cette fonctionnalité est conçue pour éviter une transmission de données inefficace en garantissant que le serveur vérifie si la demande peut être acceptée sur la base uniquement des en-têtes. Les clients doivent envoyer Attendez-vous: 100-continue comme en-tête et attendez un code d'état 100 Continue avant de continuer, ou un 417 Expectation Failed si la demande est rejetée.

Journaux : activez ou désactivez les journaux de trafic de la batterie de serveurs pour déboguer et analyser le trafic passant par l'équilibreur de charge.

Expiration du délai de connexion back-end: Cette valeur définit le temps pendant lequel la batterie attendra une connexion au backend, généralement le temps d'attente d'ouverture du socket, en secondes. La valeur par défaut est de 20 secondes.

Fréquence de vérification des backends ressuscités: ce paramètre détermine la fréquence à laquelle l'équilibreur de charge vérifie si un backend précédemment mis sur liste noire est accessible et le supprime de la liste noire s'il est actif. La batterie de serveurs vérifie périodiquement le backend une fois qu'il est marqué, quelles que soient les nouvelles connexions client. La valeur par défaut est de 10 secondes.

Délai d'expiration de la réponse du backend: Cette valeur définit le temps pendant lequel la batterie attendra une réponse des backends en secondes. La valeur par défaut est de 45 secondes.

Délai d'expiration de la demande client: Cette valeur définit le temps pendant lequel la batterie attendra la demande d'un client. Si aucune donnée n'est reçue pendant ce délai, la connexion sera interrompue. La valeur par défaut est de 30 secondes.

Messages d'erreur HTTP #

Le service de ferme affichera des messages personnalisés sur votre site lorsque des erreurs de code Web spécifiques sont détectées sur les serveurs réels. Des pages HTML personnalisées seront affichées pour les codes d'erreur 414, 500, 501, 503 et WAF 403.

• 414 : URI de requête trop long. Cette erreur se produit lorsque l'URI dépasse la longueur maximale autorisée. Si vous recevez cette erreur, raccourcissez la longueur de l'URL.
• 500 : Erreur interne du serveur. Cette erreur indique que le backend a rencontré une commande inattendue.
• 501 : Non implémenté. Cette erreur se produit lorsque le verbe de requête n'est pas reconnu ou géré par le proxy ou le backend.
• 503 Service Indisponible. Cette erreur indique que le proxy n'a pas pu trouver de backend disponible pour la requête. Cela peut se produire si tous les backends sont en panne ou si l'expression régulière de la requête ne correspond à aucun service configuré.
• WAF 403 : Interdit. Cette erreur se produit si le pare-feu d'application Web (WAF) est activé et que le moteur WAF rejette la demande.

En-têtes #

Dans cette section, vous pouvez globalement ajouter ou supprimer des en-têtes de demande et de réponse, en appliquant ces actions à tous les services configurés. Si un en-tête est configuré dans la section service, cette configuration spécifique sera remplacée.

Les actions à utiliser dans cette section incluent :

Créer une règle. Une règle d'en-tête globale sera créée.
Supprimer . Une règle d'en-tête globale sera supprimée.

Cette section vous permet d'ajouter ou de créer En-tête demandes et réponses, comme illustré dans l’image ci-dessous.

Type.

• Demande : supprimer l'en-tête. Supprime le modèle d'en-tête spécifié des requêtes HTTP client.
• Demande : ajouter un en-tête. Ajoute l'en-tête spécifié aux requêtes HTTP du client.
• Réponse : supprimer l'en-tête. Supprime le modèle d'en-tête spécifié des réponses HTTP backend.
• Réponse : ajouter un en-tête. Ajoute l'en-tête spécifié aux réponses HTTP du backend.

En-tête. Indiquez l'en-tête à ajouter ou à supprimer.
Valeur. Indiquez la valeur de l'en-tête donné si nécessaire.

Paramètres de services #

Les services d'une batterie LSLB utilisant un profil HTTP permettent la commutation de contenu pour les services virtuels Web, en consolidant plusieurs applications Web sous le même IP virtuel et PORT. Cette configuration facilite gestion centralisée des applications web, configurations d'hôte virtuel, Gestion des URL, configurations de redirection et configurations de persistance et de backend par service. Chaque service d'une batterie LSLB comprend des propriétés pour les vérifications de l'état, la persistance, la gestion des en-têtes et une liste de back-ends. Des expressions régulières peuvent être appliquées pour faire correspondre les conditions qui dictent quel service gère chaque demande.

Le profil de la ferme HTTP évalue les conditions de correspondance des services en mode prioritaire (modifiable selon les besoins). Si aucun service ne correspond, la batterie renvoie une erreur HTTP 503. Par conséquent, la définition de plusieurs services avec des conditions spécifiques est prise en charge. Les requêtes correspondent aux services en fonction des modèles d'hôte virtuel et/ou d'URL.

Il est essentiel de d'abord créer et ajouter au moins un serveur backend à un service. Après avoir appliqué le nouveau service, les services HTTP sont évalués séquentiellement de haut en bas dans l'ordre de la liste. Le premier service correspondant dans les champs Hôte et/ou URL traite la demande entrante en fonction des modèles d'URL ou d'hôte configurés.

Les conditions à remplir sont :

hôte virtuel. Cette fonctionnalité vous permet de définir une condition basée sur le nom de domaine en utilisant la même adresse IP virtuelle et le même port au sein d'une batterie HTTP. Si vous souhaitez supprimer cette condition, vous pouvez laisser le champ vide. Expressions régulières dans PCRE formats sont pris en charge dans ce champ.

Modèle d'URL. Le but de ce champ est d'identifier un service Web en fonction du chemin URL demandé par le client. L'URL sera évaluée par rapport à un modèle désigné, garantissant que sa syntaxe est correcte. Si vous souhaitez ignorer cette condition, vous pouvez laisser le champ vide. Expressions régulières dans PCRE formats sont pris en charge dans ce champ, permettant une correspondance de modèles avancée.

L'espace hôte virtuel et Modèle d'URL les valeurs sont des expressions régulières. Si laissé vide, n'importe quelle valeur correspondra. Les deux champs doivent correspondre ou il passera au service suivant. Il est recommandé d'en utiliser au moins un, servant de valeur par défaut s'il n'y a pas de correspondance détectée en bas.

Planificateur d'équilibrage de charge. Ce champ spécifie l'algorithme utilisé pour répartir la charge entre les serveurs backend. L'algorithme sélectionné par défaut est basé sur le poids.

• Poids: connexion linéaire en fonction du poids. Distribue les connexions en fonction des pondérations attribuées à chaque backend. Les requêtes sont livrées de manière probabiliste selon les poids définis.
• Least Response : poids dynamique en fonction de la réponse du backend. Ajuste dynamiquement les pondérations du backend en fonction de leurs temps de réponse. Des réponses plus rapides augmentent la probabilité que les connexions soient dirigées vers ces serveurs.

Réorienter #

Si l'option de redirection du service est activée, les serveurs principaux ne peuvent pas être utilisés car toutes les requêtes seront envoyées à l'URL spécifiée.

Type de redirection. Il existe deux types de redirections :

• Réglage par défaut : prend l'URL comme hôte absolu et chemin vers lequel rediriger.
• Ajouter: ajoute le chemin de la demande d'origine à l'hôte et au chemin spécifiés.

URL de redirection. Spécifie où le client doit être redirigé après avoir reçu une réponse. Si une valeur de redirection est configurée, vous ne pouvez pas configurer les backends pour ce service. Lorsque l'hôte virtuel et le modèle d'URL correspondent, l'appliance envoie un En-tête d'emplacement HTTP réponse pour rediriger le client vers l’URL configurée.

Code de redirection. Spécifie le code d'état HTTP pour la redirection :

• 301 Déménagé Définitivement)
• 302 (déplacé temporairement)
• 307 (Redirection temporaire)

Persistence #

Ce paramètre définit la manière dont le service HTTP gère les sessions client et contrôle quelles connexions HTTP sont maintenues pour garantir des sessions client stables. Une fois qu'un type de session de persistance est sélectionné, sa durée de vie (TTL) en secondes sera affichée.

Pas de persistance. Cette option permet de transmettre des requêtes HTTP ou HTTPS à de vrais serveurs sans gérer les sessions client.
IP: adresse du client. Cette option utilise l'adresse IP du client pour maintenir des sessions client ouvertes sur des serveurs réels.
BASIC: authentification de base. Cette option utilise l'en-tête d'authentification de base HTTP pour contrôler les sessions client. Par exemple, lorsqu'une page Web nécessite une authentification de base de la part du client, un en-tête HTTP contiendra une chaîne semblable à la suivante :

		HTTP/1.1 401 Autorisation requise Serveur : HTTPd/1.0 Date : samedi 27 novembre 2011 10:18:15 GMT
		WWW-Authentification : Basic realm="Secure Area"
		Type de contenu : texte/HTML Longueur du contenu : 31

Ensuite, le client répond avec l'en-tête:

                GET /private/index.html Hôte HTTP/1.1 : localhost
		Autorisation : Basique QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Cette chaîne d'authentification de base est utilisée comme identifiant pour la session afin d'identifier la session client.
PARM : un paramètre URI. Une autre façon d'identifier une session client consiste à utiliser un paramètre URI séparé d'un point-virgule utilisé comme identifiant de session utilisateur. Dans l'exemple http://www.example.com/private.php;EFD4Y7 le paramètre sera utilisé comme identifiant de session.
URL: un paramètre de requête. Lorsque l'ID de session est envoyé via un paramètre GET avec l'URL, ce paramètre indique que le nom associé à l'ID de session client sera possible. Par exemple, une demande client comme http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 doit être configuré avec le paramètre Identifiant de session de persistance (valeur sid dans cet exemple) et la durée de vie de la session de persistance (TTL)
BISCUIT: . Vous pourrez sélectionner une variable de cookie HTTP à lire à partir des en-têtes HTTP et l'utiliser pour maintenir les sessions client pendant un temps donné. Le nom de cookie configuré dans le identifiant de session de persistance est créé par un programmeur et intégré dans une page Web pour identifier la session client, par exemple :

                GET /spec.html Hôte HTTP/1.1 : www.example.org
                Cookie : sessionidexample=75HRSd4356SDBfrte

De plus, la durée de vie de la session de persistance (TTL) doit être configurée. Cette valeur gère le temps économisé par l'équilibreur de charge lorsque le client et le backend restent sans aucune activité.
HEADER : un en-tête de requête. Un champ personnalisé d'en-tête HTTP peut être utilisé pour identifier la session client. La durée de vie de la session de persistance et l'identifiant de session de persistance doivent être configurés. Par exemple:

               GET /index.html Hôte HTTP/1.1 : www.example.org
               X-session : 75HRSd4356SDBfrte

Cookie Insert #

S'il est configuré, l'équilibreur de charge générera un gâteau dans chaque réponse en utilisant la clé backend appropriée. Cela garantit que même si le tableau des sessions est effacé ou si les sessions sont désactivées, le bon backend sera toujours sélectionné. Cette fonctionnalité élimine le besoin de modifier le code réel du serveur pour créer un cookie de session.

L'espace Nom Cookie spécifie le nom du cookie créé et inclus dans la demande du client ou la réponse du backend. Le Chemin des cookies définit l'URI ou le chemin relatif où le nouveau cookie sera établi. Pour appliquer le cookie sur l'ensemble du domaine, définissez ce champ en conséquence. Le Domaine du cookie indique le domaine dans lequel le cookie sera installé. Enfin, le Cookie TTL indique le nombre de secondes pendant lesquelles le cookie reste actif entre le client et le backend. Cette valeur doit dépasser 0 et elle concerne la durée sans aucune activité. Une fois le temps spécifié écoulé sans activité, la session de persistance associée au cookie expirera.

Farmguardian #

Les fermes HTTP fournissent une vérification de l'état de base et native du backend, mais la configuration Farmguardian est recommandée pour des vérifications de l'état heuristiques plus intelligentes du backend afin de garantir que l'application est saine.

Certaines vérifications de l'état avancées ou personnalisées peuvent être attribuées à ce service à partir des vérifications Farmguardian déjà créées.

Pour plus d'informations sur Farmguardian, allez à Surveillance> Farmguardian .

Notez qu'après avoir sélectionné Farmguardian, il sera automatiquement appliqué à la ferme.

Les backends HTTPS. Cette case à cocher indique à la ferme que les serveurs backend définis dans le service courant utilisent le protocole HTTPS donc les données seront chiffrées avant d'être envoyées.

Backends #

En ce qui concerne la Backends, le profil HTTP de la ferme permet de configurer les propriétés suivantes : Tous les backends doivent être IPv4 ou IPv6, et avec la même version IP que la Farm VIP.

Ajouter un serveur principal #

Grâce à la Action bouton de menu, les actions suivantes sont disponibles pour un ou plusieurs backends sélectionnés :
Ajouter le backend. Cette commande ouvre le formulaire de création du backend.
Les actions citées ci-dessus : Activer la maintenance (Vidanger et Cut/Taille mode), Désactiver la maintenance et Supprimer .

Liste back-end #

Action. Utilisez les actions suivantes pour gérer les backends :

• Activer la maintenance. Utilisez cette action si le backend a été précédemment désactivé. Placer un serveur réel en mode maintenance signifie qu'aucune nouvelle connexion ne sera redirigée vers celui-ci. Il existe deux méthodes pour activer le mode maintenance :
  • Mode vidange. Conserve les connexions établies et la persistance si activé, mais n'admet pas de nouvelles connexions.
  • Mode de coupe. Supprime toutes les connexions actives contre le backend
• Désactiver la maintenance. Utilisez cette action lorsque le backend est en mode maintenance. Activez à nouveau les nouvelles connexions au serveur réel après avoir désactivé le mode de maintenance.
• Supprimer . Supprimer les configurations d'un service virtuel sélectionné. L'alias ne sera pas supprimé s'il y en a un.

Alias. Alias ​​de base, si un alias a été sélectionné.
IP. L'adresse IP d'un backend donné.
Port. Le numéro de port du serveur réel actuel.
Temps mort. Le temps qu'un backend met pour répondre. Cette valeur remplace le paramètre du délai d'expiration global de la connexion au backend, mais elle est limitée à la batterie sélectionnée.
Poids. La valeur de pondération pour le serveur réel actuel. Plus de poids indique plus de connexions livrées au backend actuel. Par défaut, une valeur de poids de 1 sera définie. La plage de valeurs disponible est de 1 à 9.
. Les valeurs possibles sont :

• Up. La ferme est en cours d'exécution et le backend est prêt à recevoir des connexions.
• Vers le bas. La ferme est en cours d'exécution et le service a détecté que le backend ne fonctionne pas
• Entretien. Le backend est marqué comme n'étant pas prêt à recevoir des connexions par l'administrateur, cette option est utile pour les tâches de maintenance du backend
• Indéfini. L'état du backend n'a pas été vérifié.

Priorité. La valeur de priorité pour le serveur réel actuel. Les valeurs inférieures ont plus de priorité. La valeur de priorité de service par défaut est 1. Lorsqu'un backend échoue, la priorité de service est augmentée de 1. Lorsque le backend est à nouveau actif, la valeur de priorité de service est diminuée de 1. Les backends actifs contiennent des valeurs de priorité inférieures ou égales à la priorité de service .

Règles IPDS pour les batteries HTTP #

Cette section vous permet d'activer les règles IPDS. La liste affiche différents types de protection avec une case de sélection pour les activer. Pour plus d'informations, veuillez vous référer à la documentation spécifique à IPDS > Règles des listes noires, IPDS > Règles DoS, IPDS > Règles RBL or IPDS > Règles WAF.

Pour chacun des quatre types de règles IPDS (Blacklist, DoS, WAF et RBL), il existe deux listes : Disponible et Les utilisateurs de l’app Smart Spaces avec Google Wallet profitent d’un accès mobile sans contact avec tout lecteur HID® Signo™ compatible NFC.. Une icône de chaîne est également présente. Dans le Disponible Dans la liste, vous trouverez des règles du même type pouvant être appliquées à une ferme donnée. Dans le Les utilisateurs de l’app Smart Spaces avec Google Wallet profitent d’un accès mobile sans contact avec tout lecteur HID® Signo™ compatible NFC. liste, vous verrez les règles actuellement appliquées à la ferme sélectionnée, indiquées par leur symbole de statut : rouge pour arrêté et et une transition qui soit juste. pour courrir.

Chaque règle peut être modifiée en cliquant sur l'icône d'édition, ce qui vous permet de modifier les paramètres de la règle ou de démarrer/arrêter la règle. Notez que de nouvelles règles ne peuvent pas être créées dans cette vue de batterie et doivent être gérées via le IPDS .

Pour ajouter une règle, cliquez sur la règle souhaitée, puis cliquez sur la flèche simple droite. Vous pouvez également sélectionner plusieurs règles en maintenant la touche Maj enfoncée et en sélectionnant les règles souhaitées avant de cliquer sur la flèche simple droite. Pour ajouter toutes les listes noires disponibles, cliquez sur la double flèche droite.

Pour supprimer une ou plusieurs règles, sélectionnez-les et cliquez sur la flèche gauche ou cliquez sur la double flèche pour toutes les supprimer.