Contenu
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.
Environment
Le diagramme suivant décrit les composants internes du Zevenet WAF. Comme il est montré, la première couche est le module WAF dont le but est de garantir à un stade précoce que seules les demandes sécurisées sont autorisées à passer au module d'équilibrage de charge, puis à la transmettre aux serveurs principaux.
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éation.
Maintenant, cliquez sur l'onglet supérieur Prestations 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/zevenet/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/zevenet/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.
Cliquez sur 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 standard, 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 Jouez dans la partie supérieure gauche de cette fenêtre et le système commencera à filtrer le trafic HTTP pour la batterie standard.
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 "Host: www.mycompany1.com" http://192.168.100.58 -v * Rebuilt URL to: http://192.168.100.58/ * Trying 192.168.100.58... * TCP_NODELAY set * Connected to 192.168.100.58 (192.168.100.58) port 80 (#0) > GET / HTTP/1.1 > Host: www.mycompany1.com > User-Agent: curl/7.52.1 > Accept: */* > < HTTP/1.1 200 OK < Server: nginx/1.10.3 < Date: Tue, 10 Sep 2019 15:36:22 GMT < Content-Type: text/html < Content-Length: 11383 < Last-Modified: Thu, 13 Dec 2018 11:01:49 GMT < Connection: keep-alive < ETag: "5c123c1d-2c77" < Accept-Ranges: bytes <
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 "Host: www.mycompany2.com" http://192.168.100.58 -v * Rebuilt URL to: http://192.168.100.58/ * Trying 192.168.100.58... * TCP_NODELAY set * Connected to 192.168.100.58 (192.168.100.58) port 80 (#0) > GET / HTTP/1.1 > Host: www.mycompany2.com > User-Agent: curl/7.52.1 > Accept: */* > * HTTP 1.0, assume close after body < HTTP/1.0 403 Request forbidden < Content-Type: text/html < Content-Length: 17 < Expires: now < Pragma: no-cache < Cache-control: no-cache,no-store < * Curl_http_done: called premature == 0 * Closing connection 0 replied forbiddenp
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 Sep 10 15:38:44 zva6000 pound: Hosting, ModSecurity: Warning. Matched "Operator `StrMatch' with parameter `mycompany2.com' against variable `SERVER_NAME' (Value: `www.mycompany2.com' ) [file "/usr/local/zevenet/config/ipds/waf/sets/HostingBlacklisting.conf"] [line "17"] [id "1001"] [rev ""] [msg "Custom Match 2"] [data ""] [severity "0"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "192.168.100.58"] [uri "/"] [unique_id "156812992458.770641"] [ref "v0,13v21,18"] Sep 10 15:38:44 zva6000 pound: Hosting, [WAF,service mycompany2, backend 192.168.100.22:80,] (7f6cfac3c700) [client 192.168.1.191] ModSecurity: Access denied with code 403 (phase 1). Matched "Operator `StrMatch' with parameter `mycompany2.com' against variable `SERVER_NAME' (Value: `www.mycompany2.com' ) [file "/usr/local/zevenet/config/ipds/waf/sets/HostingBlacklisting.conf"] [line "17"] [id "1001"] [rev ""] [msg "Custom Match 2"] [data ""] [severity "0"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "192.168.100.58"] [uri "/"] [unique_id "156812992458.770641"] [ref "v0,13v21,18"] Sep 10 15:38:44 zva6ktpl1 pound: Hosting, service mycompany2, backend 192.168.100.25:80, (7f6cfac3c700) WAF denied a request from 192.168.1.191
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.