Mes collègues d’Edgenexus pensent généralement que les équilibreurs de charge F5 LTM sont extrêmement puissants et flexibles, mais que l’utilisation de scripts iRules pour exécuter certaines fonctions de base entraîne une complexité inutile.
Il suffit de faire une recherche en ligne sur les iRules F5 pour découvrir la douleur et l’angoisse qu’éprouvent de nombreux professionnels de l’informatique dans le processus de création d’iRules fonctionnelles. S’il est vrai que l’extension de la fonctionnalité » Local Traffic Policies » dans les dernières versions du logiciel F5 a supprimé en partie la nécessité de créer des iRules pour les fonctions courantes de manipulation des en-têtes HTTP, de nombreux utilisateurs sont encore coincés avec des iRules héritées dans la configuration de leur système.
Les politiques de trafic local ne semblent pas permettre la manipulation des données HTML, bien que les politiques de flux le fassent, elles sont plutôt lourdes et difficiles à contrôler. Par défaut, elles affectent le trafic dans les deux sens de la même manière, ce qui n’est généralement pas souhaitable. Cela signifie qu’il faut revenir aux iRules pour exécuter des fonctions telles que le remplacement d’un lien de corps de texte d’une URL de http:// à https://, qui peut être nécessaire en conjonction avec une redirection de http:// à https, qui peut être effectuée à l’aide des règles de gestion du trafic local.
Entrez dans flightPATH d’Edgenexus – La gestion du trafic en toute simplicité
Chez Edgenexus, nous sommes fiers, à juste titre, de la puissance et de la simplicité de configuration de notre fonction de manipulation HTTP de la couche 7 de flightPATH.
Si vous êtes un utilisateur existant de F5, utilisant iRules pour la manipulation HTTP ou HTML, nous serions ravis d’avoir l’opportunité de vous faire une démonstration de l’équilibreur de charge Edgenexus ALB-X et de vous montrer à quel point flightPATH est facile à configurer pour réaliser des fonctions relativement complexes. Nous aimerions être mis à l’épreuve pour vous aider à traduire vos fonctions iRules existantes en règles flightPATH.
A titre d’exemple, nous avons reproduit ci-dessous une sélection d’iRules F5 avec les captures d’écran équivalentes de la configuration de la règle flightPATH d’Edgenexus.
Source IP Content Server Steering
Voici un exemple de la manière dont les iRules F5 peuvent être utilisées pour diriger les utilisateurs d’une certaine plage d’adresses IP vers un pool de serveurs et ceux d’une autre plage vers un autre pool de serveurs.
F5 :
| Nom : | IP_Choice |
| Définition : | when HTTP_REQUEST { if { ( [IP::addr [IP::client_addr] equals 24.24.15.100] ) or ( [IP::addr [IP::client_addr] equals 10.1.1.2] ) } { pool pool2 } } |
Edgenexus :
- Créez une nouvelle règle flightPATH avec le nom IP_Choice_Pool_1 via l’interface graphique Web. Ajoutez une description concise pour pouvoir identifier la fonction de la règle flightPATH.
- Ajoutez une nouvelle condition, en sélectionnant Source IP dans la liste déroulante étendue. Sélectionnez « Does » dans la liste déroulante Sense. Une option consiste à sélectionner Start dans la liste déroulante Check list (vous pouvez également utiliser d’autres options telles que RegEx pour offrir plus de souplesse à l’adresse IP « Value »). Saisissez la plage d’adresses IP de départ dans le champ Valeur.
- Ajoutez une nouvelle action. Dans le menu déroulant Action, choisissez l’option Utiliser un serveur (il existe également une option Utiliser un serveur sécurisé si nécessaire). Dans la case Cible, entrez l’adresse IP et le port de la destination requise. Il s’agit généralement d’une autre interface de service virtuel pour permettre l’équilibrage de la charge sur un autre groupe de serveurs réels.
Redirection HTTP vers HTTPS
Bien que F5 propose désormais une alternative à l’utilisation d’iRules pour effectuer une redirection HTTP vers HTTPs, il existe de nombreux cas où les utilisateurs continuent d’utiliser iRules pour cette fonction. iRules permet également une plus grande personnalisation des paramètres de redirection.
F5 :
| Nom : | Redirection HTTP_HTTPs |
| Définition : | when HTTP_REQUEST { HTTP::redirect « https://[HTTP::host][HTTP::uri] » } |
Edgenexus :
- Créez une nouvelle règle flightPATH avec le nom Redirect HTTP to HTTPS via the Web GUI. Ajoutez une description concise pour pouvoir identifier la fonction de la règle flightPATH.
- Pour la plupart des applications, la redirection HTTP vers HTTPS doit être effectuée sur l’ensemble du trafic touchant le service HTTP. Dans ce cas, il n’est pas nécessaire de créer une règle de condition. Il existe une grande flexibilité pour créer des règles de condition si la règle flightPATH ne doit affecter que certains trafics.
- Ajoutez une nouvelle action en choisissant Redirect 302 dans la liste déroulante Action (Redirect 301 est également disponible). L’ALB-X d’Edgenexus crée automatiquement des variables pour certains paramètres clés du trafic traité par l’ALB-X, notamment l’hôte, le chemin et la chaîne de requête. Dans la case Target, entrez les détails de l’endroit où la requête doit être redirigée. Dans ce cas, faites précéder l’entrée https:// et utilisez les variables $host$$path$$querystring$ pour insérer les données de la requête http originale. Comme vous pouvez le constater, il est possible de définir une destination complètement différente si nécessaire.
Masquer les numéros de cartes de crédit
Voici un exemple de la complexité des iRules et de la manière dont F5 gère la manipulation du corps HTML.
F5 :
| Nom : | Masquage du numéro de carte de crédit |
| Définition : | when HTTP_REQUEST { # Empêcher le serveur d’envoyer une réponse compressée # supprimer les offres de compression du client HTTP::header enlever « Accept-Encoding » # Ne pas autoriser les données de réponse à être fragmentées (chunked) if { [HTTP::version] eq « 1.1 » } { # Forcer le passage à HTTP 1.0, tout en autorisant les connexions de type « keep-alive ». # Puisque HTTP 1.1 est keep-alive par défaut, et que 1.0 ne l’est pas, # nous devons nous assurer que les en-têtes reflètent le statut « keep-alive ». # Vérifier s’il s’agit d’une connexion maintenue en vie if { [HTTP::header is_keepalive] } { # Remplacer la valeur de l’en-tête de connexion par « Keep-Alive » HTTP::header replace « Connection » « Keep-Alive » } # Fixer la version de la requête côté serveur à 1.0 # Ceci force le serveur à répondre sans chunking HTTP::version « 1.0 » } } when HTTP_RESPONSE { # Ne vérifiez que les réponses dont le contenu est de type texte (text/html, text/xml, text/plain, etc.). if { [HTTP::header « Content-Type »] starts_with « text/ » } { # Obtenir la longueur du contenu pour pouvoir collecter les données (à traiter dans l’événement HTTP_RESPONSE_DATA) # Limiter la collecte à 1Mb (1048576 moins un peu de réserve) – Voir SOL6578 pour plus de détails if { [HTTP::header exists « Content-Length »] } { if { [HTTP::header « Content-Length »] > 1048000 }{ # Content-Length over 1Mb so collect 1Mb set content_length 1048000 } else { # Content-Length under 1Mb so collect actual length (longueur du contenu inférieure à 1 Mo) set content_length [HTTP::header « Content-Length »] } } else { # La réponse n’avait pas d’en-tête Content-Length, utilisez donc la valeur par défaut de 1Mb. set content_length 1048000 } # Ne pas collecter le contenu si la valeur de l’en-tête Content-Length est 0 if { $content_length > 0 } { HTTP::collect $content_length } } } when HTTP_RESPONSE_DATA { # Trouver TOUS les numéros de carte de crédit possibles en une seule passe set card_indices [regexp -all -inline -indices\N-]. {(?:3[4|7]\d{2})(? :[ ,-] ?(?:\d{5}(?:\d{1}) ?)){2}|(?:4\d{3})(? :[ ,-] ?(?:\d{4})){3}|(?:5[1-5]\d{2})(? :[ ,-] ?(?:\d{4})){3}|(?:6011)(? :[ ,-] ?(?:\d{4})){3}}\ [HTTP::payload]] foreach card_idx $card_indices { set card_start [lindex $card_idx 0] set card_end [lindex $card_idx 1] set card_len [expr {$card_end – $card_start + 1}] set card_number [string range [HTTP::payload] $card_start $card_end] # Supprimez le tiret ou l’espace s’ils existent et comptez les occurrences dans les découpes variables. set cutouts [regsub -all {[-]} $card_number « » card_number] # Adjsut card_len variable but keep it for later use. set new_card_len [expr {$card_len – $cutouts}] set double [expr {$new_card_len & 1}] set chksum 0 set isCard invalid # Calculer le MOD10 for { set i 0 } { $i < $new_card_len } { incr i } { set c [string index $card_number $i] if {($i & 1) == $double} { if {[incr c $c] >= 10} {incr c -9} } incr chksum $c } # Déterminer le type de carte switch [string index $card_number 0] { 3 { set type AmericanExpress } 4 { set type Visa } 5 { set type MasterCard } 6 { set type Discover } default { set type Unknown } } # Si le numéro de la carte est valide, masquer les chiffres par des X if { ($chksum % 10) == 0 } { set isCard valid HTTP::payload replace $card_start $card_len [string repeat « X » $card_len] } # Résultats du journal log local0. « Found $isCard $type CC# $card_number » } } |
Edgenexus :
- Créez une nouvelle règle flightPATH et fournissez une description pertinente.
- Il s’agit là d’un autre exemple où la correspondance des conditions n’est pas forcément nécessaire, car vous souhaitez normalement protéger les réponses du serveur. L’option existe bien sûr si vous le souhaitez.
- Ajoutez une nouvelle « action » et choisissez « Remplacer tout le corps » dans le menu déroulant. Des expressions régulières sont utilisées pour faire correspondre le texte cible à remplacer par cette action. Utilisez \b(?:\d[ \t-] ?){12}\b comme cible pour détecter et remplacer les 12 premiers chiffres des numéros de cartes de crédit. Dans le champ Données, entrez xxxx-xxxx-xxxx comme texte de remplacement. Les 4 derniers chiffres resteront ainsi intacts en tant qu’identifiant.
- Répétez le processus ci-dessus pour d’autres types de données sensibles telles que les numéros d’assurance nationale en utilisant \b(?:\d[ \t-] ?){7}\b remplacé par xxx-xxxx et \b(?:\d[ \t-] ?){6}\b remplacé par xxx.xxx.
- Grâce à une utilisation judicieuse des expressions régulières, il est possible de faire correspondre et de masquer une grande variété de séquences de caractères en utilisant simplement l’action Remplacer le corps. Les options Remplacer le corps en premier et Remplacer le corps en dernier sont d’autres options d’action qui peuvent être utilisées lorsque seule la première ou la dernière occurrence d’une séquence de caractères sur une page doit être remplacée.
Supprimez les en-têtes X- susceptibles de compromettre la sécurité
On cite souvent comme bonne pratique d’éviter de fournir des informations inutiles sur l’infrastructure du serveur utilisée pour la livraison d’une application, en supprimant certains en-têtes HTTP qui sont insérés par défaut par l’application ou la technologie du serveur. Plus un pirate en sait sur le système qu’il cherche à exploiter, plus il lui est facile de le faire. Il y a souvent un décalage entre la publication des vulnérabilités des systèmes et la mise en place des correctifs. C’est au cours de cette période que les systèmes sont le plus menacés et que le processus d’obscurcissement des détails de la plateforme de livraison d’applications est le plus utile.
De nombreuses informations inutiles sont contenues dans les X-Headers. L’iRule suivante effectue une suppression globale des X-Headers, ce qui n’est pas forcément souhaitable.
F5 :
| Nom : | HTTP Suppression de l’en-tête du serveur X |
| Définition : | when HTTP_RESPONSE { # Supprimez toutes les instances de l’en-tête Serveur HTTP::header remove Serveur # Supprimer tous les en-têtes commençant par x- foreach header_name [HTTP::header names] { if {[string match -nocase x-* $header_name]}{ HTTP::header remove $header_name } } } |
Edgenexus :
- Créez une nouvelle règle flightPATH avec un nom significatif, par exemple Remove HTTP Headers (supprimer les en-têtes HTTP).
- Il s’agit d’un exemple de règle flightPATH pour laquelle aucune condition n’est requise. Un ensemble complet de critères de sélection est disponible si nécessaire.
- Ajoutez une nouvelle action « Supprimer l’en-tête de la réponse », dans le champ Cible, saisissez la valeur de l’en-tête à supprimer. Ajoutez une entrée d’action « Remove Response Header » pour définir chacun des champs d’en-tête que vous souhaitez masquer dans les réponses du serveur. Une action générale de suppression de tous les en-têtes personnalisés préfixés en X pourrait en fait avoir un effet préjudiciable, c’est pourquoi flightPATH vous demande de définir les en-têtes spécifiques qui doivent être supprimés.
- Appliquez le flightPATH créé à chacun des services où l’action est requise.
Application des règles flightPATH aux services virtuels
flightPATH est un outil de manipulation HTTP très puissant, mais simple à utiliser. Vous pouvez créer une « bibliothèque » de règles flightPATH pour effectuer diverses actions sur le trafic HTTP lorsqu’il traverse le dispositif d’équilibrage de charge ALB-X. Plusieurs règles flightPATH peuvent être appliquées à un service virtuel. Les règles flightPATH sont traitées dans l’ordre dans lequel elles sont appliquées au service. Certaines règles flightPATH interrompent le traitement. Vous pouvez utiliser la fonction « glisser-déposer » pour réorganiser l’ordre et vous assurer que toutes les actions sont exécutées comme il se doit. edgeNEXUS peut proposer des services professionnels pour vous aider à traduire et à créer des règles flightPATH plus complexes.
Vous voulez en savoir plus ?
Pour plus d’informations sur la manipulation du trafic par Edgenexus , cliquez ici.
Pour télécharger une version d’essai gratuite de l’ALB-X , cliquez ici.
Nous serions heureux d’avoir l’occasion de vous présenter les fonctionnalités d’Edgenexus ALB-X et flightPATH. Demandez une démonstration technique rapide et personnalisée ici.
