Aperçu #
L'article suivant décrit un cas d'utilisation réel pour un fournisseur d'accès Internet ou un fournisseur d'hébergement, où le proxy inverse HTTP / S Load Balancer est le point d'accès principal à tous les services Web publics. Cette configuration montre à quel point il est facile de configurer un WAF avancé et puissant. règles afin de sécuriser les applications Web basées sur les adresses IP source de la liste noire, où chaque VirtualHost gère sa propre liste noire de manière à interdire à une adresse IP publique de se connecter à un domaine Web tel que www.company1.com mais autorisé à se connecter à www.company2.com.
Nous allons centrer l’article sur deux sections. Dans la section principale, la configuration du profil HTTPS fonctionnera comme un proxy inverse avec une liste de différents services. La seconde section explique comment configurer un Pare-feu d'applications Web ensemble de règles qui gérera une liste noire différente par service HTTP / S.
Environnement #
Le diagramme suivant décrit le RELIANOID Éléments internes du WAF. Comme indiqué, la première couche est le module WAF dont l'objectif est de garantir dès le début que seules les requêtes sûres sont autorisées à transiter vers le module d'équilibrage de charge, puis à transmettre la requête aux backends.
Tout d'abord, le HTTP Hôte l'en-tête est évalué et l'adresse IP du client est vérifiée dans la liste noire déjà configurée. Si la Hôte en-tête et l'adresse IP du client correspond alors la connexion est abandonnée et un 403 Interdite La réponse HTTP est envoyée au client, mais dans le cas où l'IP du client et demandé Hôte l'en-tête ne correspond pas, le trafic est identifié comme non malveillant et transmis au module d'équilibrage de charge, où la destination est choisie en fonction de la requête HTTP Hôte en-tête et finalement transmis au serveur principal disponible.
Vous trouverez ici un schéma des éléments internes de Web Application Firewall pour l'exemple donné.
Configuration du service virtuel HTTP #
Configurez un dédié Adresse IP virtuelle, dans notre exemple 192.168.100.58, en naviguant vers Réseau> Interfaces virtuelles> Créer une interface virtuelle comme indiqué ci-dessous:
Passons maintenant à la configuration du service d'équilibrage de charge HTTP, allez à LSLB> Fermes puis cliquez sur le bouton Créer une ferme et entrez les détails du service virtuel comme indiqué ci-dessous:
Puis appuyez Créer.
Maintenant, cliquez sur l'onglet supérieur Services et créez autant de services que différents sites Web que vous gérez, cliquez sur le bouton Nouveau service, dans notre cas, nous allons créer deux services différents, l’un pour gérer le service pour www.mycompany1.com et un autre pour www.mycompany2.com.
Une fois le service créé, ajoutez le hôte virtuel filtre et les backends comme il est montré dans l'image ci-dessous.
Si vous avez plusieurs sites Web, il vous suffit d'ajouter plusieurs services pour définir un service dédié permettant de gérer chaque site Web à partir de la même adresse IP.
La configuration de l'équilibrage de la charge est maintenant terminée. Permet de configurer le module IPDS Web Application Firewall.
Configuration des listes noires #
Nous allons créer une liste noire par service Web afin de saisir dans chaque liste noire les adresses IP souhaitées pour bloquer l'accès. Dans notre exemple, nous allons créer deux listes noires différentes avec le nom blacklistmycompany1 et blacklistmycompany2, un par service respectivement.
Cette liste noire sera sauvegardée dans le chemin /usr/local/relianoid/config/ipds/blacklists/lists/Blacklistmycompany1.txt.
Nous avons inclus les adresses IP 2 à des fins de test. Merci d’envisager d’ajouter autant d’IP que nécessaire. En outre, le déjà existant Listes noires dans le IPDS module peut être utilisé.
Cette deuxième liste noire sera sauvegardée dans le chemin /usr/local/relianoid/config/ipds/blacklists/lists/Blacklistmycompany2.txt.
Prenez en compte que dans cette liste noire nous avons inclus l'adresse IP 192.168.1.191, cette adresse IP sera utilisée à des fins de test uniquement, à partir de laquelle nous exécuterons les requêtes HTTP.
Configuration du jeu de règles du pare-feu d'application Web #
Le but de cette configuration est de gérer différentes listes noires IP par site Web, afin d'éviter de conserver la même liste noire pour l'ensemble du point d'accès de la batterie.
Nous allons configurer un ensemble de règles, qui est un groupe de règles, avec le nom HébergementBlacklisting. Ce jeu de règles sera composé de deux règles simples (ID de règle 1000 et ID de règle 1001 dans notre exemple), chaque règle est définie comme une correspondance et une action, où si la condition correspond, l'action est exécutée. Dans notre exemple, nous utiliserons la même action dans les deux règles, si la condition correspond à un Action de rejet est exécuté avec un Accès 403 refusé réponse.
Allez dans IPDS> WAF, puis cliquez sur Créer un jeu de règles WAF et définir un nom de jeu de règles descriptif, dans notre exemple HébergementBlacklisting.
Configurez le champ Phase par défaut à Les en-têtes de demande sont reçus. Ce champ signifie que le module WAF analysera les en-têtes de requête entrants provenant du client.
Ensuite, allez à l'onglet Règles et créer le premier Règle De type Action comme il est montré ci-dessous.
Maintenant la première règle du jeu de règles est créée, permet de créer les conditions afin de faire correspondre l'adresse IP du client dans la liste noire pour chaque Hôte entête. Aller à Conditions et créer une condition en fonction de la REMOTE_ADDR variable comme il est montré ci-dessous.
Créez ensuite une autre condition pour le hôte virtuel match en fonction de la SERVER_NAME variable comme suit:
À ce stade, le premier site Web hébergé www.mycompany1.com gère une adresse IP de liste noire d'applications Web à partir de la liste noire déjà configurée, Blacklistmycompany1.txt.
Créons une autre règle pour le deuxième site Web www.mycompany2.com et répétez la même configuration que la configuration de la règle précédente, mais dans ce cas, vous devez modifier SERVER_NAME à mycompany2.com et fait référence à la suivante blacklist2.txt.
Voir la configuration complète du jeu de règles WAF composé:
Enfin, ajoutez ce jeu de règles à la batterie déjà créée, allez dans l’onglet Fermes et déplacer la ferme Hébergement, dans notre exemple, au Fermes activées section comme il est montré ci-dessous.
Maintenant, démarrez le jeu de règles WAF pour la batterie, cliquez sur l'action JOUER dans la partie supérieure gauche de cette fenêtre et le système commencera à filtrer le trafic HTTP pour la batterie Hébergement.
Test du jeu de règles du pare-feu d'application Web #
L'IP du client 192.168.1.191 va demander le site http://www.mycompany1.com et http://www.mycompany2.com et, selon notre configuration, le système WAF permettra la connexion au premier service du même nom, mais la connexion sera refusée. mycompany2.com parce que cette adresse IP a été incluse dans la liste noire avec le nom Blacklistmycompany2.
De l'adresse IP 192.168.1.191 au VIP demandant le site Web www.mycompany1.com via l'équilibreur de charge:
root@192.168.1.191 :# curl -H "Hôte : www.mycompany1.com" http://192.168.100.58 -v * URL reconstruite vers : http://192.168.100.58/ * Essayer 192.168.100.58... * TCP_NODELAY défini * Connecté au port 192.168.100.58 (192.168.100.58) 80 (#0) > GET / HTTP/1.1 > Hôte : www.mycompany1.com > Agent utilisateur : curl/7.52.1 > Accepter : */* > HTTP / 1.1 200 OK < Serveur : nginx/1.10.3 < Date : mar. 10 septembre 2019 15:36:22 GMT < Type de contenu : texte/html < Longueur du contenu : 11383 < Dernière modification : jeu. 13 décembre 2018 11:01 : 49 GMT < Connexion : keep-alive < ETag : "5c123c1d-2c77" < Accept-Ranges : octets
De l'adresse IP 192.168.1.191 au VIP demandant le site Web www.mycompany2.com via l'équilibreur de charge:
root@192.168.1.191 :# curl -H "Hôte : www.mycompany2.com" http://192.168.100.58 -v * URL reconstruite vers : http://192.168.100.58/ * Essayer 192.168.100.58... * TCP_NODELAY défini * Connecté au port 192.168.100.58 (192.168.100.58) 80 (#0) > GET / HTTP/1.1 > Hôte : www.mycompany2.com > Agent utilisateur : curl/7.52.1 > Accepter : */* > * HTTP 1.0, supposez la fermeture après le corps HTTP/1.0 403 Requête interdite < Content-Type : text/html < Content-Length : 17 < Expire : maintenant < Pragma : no-cache < Cache-control : no-cache,no-store < * Curl_http_done : appelé prématurément == 0 * Fermeture de la connexion 0 a répondu interditp
Une fois que le Interdit réponse est générée, le module WAF notifie le rejet dans le fichier Syslog de l’équilibreur de charge.
root@zva6000:# tail -f /var/log/syslog 10 septembre 15:38:44 zva6000 livre : Hébergement, ModSecurity : Avertissement. Correspondance de « l'opérateur `StrMatch' avec le paramètre `mycompany2.com' à la variable `SERVER_NAME' (Valeur : `www.mycompany2.com') [fichier "/usr/local/relianoid/config/ipds/waf/sets/HostingBlacklisting.conf "] [ligne "17"] [id "1001"] [rev ""] [msg "Custom Match 2"] [data ""] [gravité "0"] [ver ""] [maturité "0"] [ précision "0"] [nom d'hôte "192.168.100.58"] [uri "/"] [id unique "156812992458.770641"] [ref "v0,13v21,18"] 10 septembre 15:38:44 zva6000 livre : hébergement, [WAF, service mycompany2, backend 192.168.100.22:80,] (7f6cfac3c700) [client 192.168.1.191] ModSecurity : Accès refusé avec le code 403 (phase 1) Correspondance "Opérateur `StrMatch' avec le paramètre `mycompany2.com' par rapport à la variable `SERVER_NAME'. (Valeur : `www.mycompany2.com' ) [fichier "/usr/local/relianoid/config/ipds/waf/sets/HostingBlacklisting.conf"] [ligne "17"] [id "1001"] [rev "" ] [msg "Custom Match 2"] [data ""] [gravité "0"] [ver ""] [maturité "0"] [précision "0"] [nom d'hôte "192.168.100.58"] [uri "/" ] [unique_id "156812992458.770641"] [ref "v0,13v21,18"] 10 septembre 15:38:44 zva6ktpl1 livre : hébergement, service mycompany2, backend 192.168.100.25:80, (7f6cfac3c700) WAF a refusé une demande de 192.168.1.191 XNUMX
Vous pouvez désormais créer vos règles de pare-feu personnalisées pour protéger vos applications Web à l'aide des techniques d'inspection approfondie des paquets HTTP / S.
