- Why Edgenexus?
- Essayer
- Products
- Solutions
- Applications
- Resources
COMPARE
READ
WATCH
SEE
Alliances and Partners
- Support
COMPARE
READ
WATCH
SEE
Alliances and Partners
Il peut être téléchargé ci-dessous (vous n'avez pas besoin d'un compte Azure)
L'ALB-X a la capacité d'exécuter des applications conteneurisées qui peuvent être réunies directement ou en utilisant le proxy de l'équilibreur de charge. Cette image a déjà été déployée 3 fois mais vous pouvez toujours aller sur l'Appstore et en déployer d'autres. 🙂
Le Web Application Firewall est l'une des nombreuses fonctionnalités supplémentaires qui peuvent être appliquées à l'équilibreur de charge ALB-X.
Nous mettrons en évidence ces paramètres au cours de ce test de conduite.
Dans un scénario réel, le WAF recevrait et inspecterait les requêtes / le trafic http du client et transmettrait ou bloquerait ces requêtes pour qu'elles n'atteignent pas votre application web, selon que la requête a déclenché une règle de pare-feu ou non.
Nous sommes partis du principe que vous ne souhaitez probablement pas soumettre votre application web à une attaque malveillante, mais que vous voulez voir comment fonctionne le WAF. (Ceci peut être facilement modifié si vous voulez tester vos vrais serveurs 🙂 ).
Nous avons donc mis en place un environnement autonome pour pouvoir exercer et démontrer le comportement du WAF.
Bien que nous examinions ici certains paramètres de configuration de base pour pouvoir utiliser ces outils, ce document ne doit pas être considéré comme un guide complet des applications.
Nous vous encourageons à visiter les portails en ligne officiels de chacun des outils pour obtenir tous les détails si vous n'êtes pas déjà familiarisé avec leur utilisation ou leur fonctionnement.
Comme toujours, vous trouverez plusieurs vidéos sur YouTube qui peuvent être utiles à consulter. Ces deux outils ont été importés rapidement et facilement dans l'environnement de conteneurs ALB-X, le même environnement que nous utilisons pour déployer le WAF (et aussi GSLB).
Les machines virtuelles déployées dans le nuage Azure utilisent l'adressage IP interne privé (IP NAT'ed) de la même manière qu'elles seraient déployées dans un environnement de centre de données standard.
Une adresse IP est attribuée à l'appareil et différents ports sont utilisés pour accéder aux différentes ressources.
Le diagramme ci-dessous montre comment les différentes fonctions communiquent.
Les applications complémentaires déployées sur l'ALB-X communiquent avec l'ALB-X via une interface réseau interne docker0. Des adresses IP leur sont automatiquement attribuées à partir du pool interne docker0.
L'ALB-X est capable de résoudre l'adresse IP de docker0 pour l'application en utilisant ce nom d'hôte interne.
Les services IP utilisant l'adresse IP privée Azure eth0 sont configurés sur l'ALB-X pour permettre l'accès externe à l'application complémentaire.
Cela permet d'utiliser la fonction de proxy inverse de l'ALB-X pour effectuer le délestage SSL et la traduction de port si nécessaire.
Voici donc tous les ports ouverts :
Lorsque vous demandez un test, une nouvelle instance de l'appliance de test WAF est créée dans Azure. Une fois qu'il a démarré, on vous indiquera le nom de l'hôte Internet qui vous permettra d'accéder à l'interface graphique Web de la plate-forme ALB-X, ainsi que la combinaison unique du nom d'utilisateur et du mot de passe.
Nous vous recommandons d'utiliser le navigateur Chrome à cette fin.
Comme nous utilisons un certificat SSL local pour l'accès à la gestion, votre navigateur vous demandera d'accepter l'alerte de sécurité. Une fois connecté, l'écran de préconfiguration des services IP s'affichera.
Nous avons nommé chacun des services pour qu'il soit facile d'identifier ce à quoi ils servent et comment vous devez construire le lien dans la barre d'adresse de votre navigateur pour accéder au service, en remplaçant le x.x.x.x par le nom d'hôte Azure ou l'adresse IP publique.
Cliquez sur Bibliothèque dans le menu de gauche et sélectionnez Modules complémentaires.
Vous pouvez voir ici les 3 Add-Ons qui ont été déployés sur la plateforme ALB-X.
Chacun a été configuré avec un conteneur ou un nom d'hôte (waf1, zap1, dvwa1) et vous pouvez voir l'adresse IP dynamique 172.31.x.x docker0 qui a été allouée lorsque l'application a été démarrée.
Notez que dans l'environnement Azure, les boutons d'accès à l'interface graphique des Add-Ons ne sont pas utilisés.
N'hésitez pas à cliquer sur le reste de l'interface graphique d'ALB-X pour vous familiariser avec le système.
Comme c'est la fonctionnalité WAF qui vous intéresse, il serait logique de jeter un coup d'œil à l'interface graphique du WAF 🙂 .
L'écran de connexion s'affiche alors.
La combinaison par défaut du nom d'utilisateur et du mot de passe est admin / jetnexus. Une fois connecté, vous verrez l'écran suivant.
Ce tableau de bord présente un résumé des événements qui ont été déclenchés par le WAF au cours des dernières 24 heures. Comme il s'agit d'un test pré-configuré, nous avons déjà défini les détails de l'hôte à protéger sur la page de gestion.
Le lecteur de test a obtenu dynamiquement l'adresse IP de l'interface privée Azure et l'a définie dans la boîte de configuration du serveur réel / VIP avec le port :8070, le port que nous avons choisi d'utiliser pour accéder au serveur web DVWA. Comme il s'agit d'un test pré-configuré, nous avons déjà défini les détails de l'hôte à protéger sur la page de gestion.
N'hésitez pas à modifier l'adresse IP pour qu'elle pointe vers votre propre serveur.
Pendant ce temps, nous jetons un coup d'œil à la page WAF Firewall.
C'est là que vous définissez le mode de fonctionnement et que vous pouvez voir quelles règles ont été détectées. Il est également possible de mettre sur liste blanche les règles que vous ne souhaitez pas bloquer.
L'ensemble de règles chargé par défaut est l'ensemble de règles de base de l'OWASP. Il contient des détails sur des milliers de vecteurs d'attaque différents, tels qu'ils ont été mis à jour par l'OWASP.
La capture d'écran ci-dessus montre le WAF fonctionnant en mode détection seule par défaut. Veuillez passer en mode détection et blocage lors du test afin que le WAF bloque activement toute attaque. Pour l'instant, vous ne devriez pas avoir d'événements, mais lorsque vous en aurez, ils seront affichés comme suit.
Vous pouvez appliquer un filtre à l'écran des événements pour vous concentrer sur les événements spécifiques que vous souhaitez observer.
Bien que nous recommandions d'utiliser le navigateur Chrome pour l'accès à la gestion des appareils, vous devrez utiliser un autre navigateur pour générer le trafic de test et je recommanderais Firefox à cette fin.
Il sera modifié lors du prochain démarrage du ZAP.
Une fois cette opération terminée, ZAP fonctionnera et la LED du service IP 8090 passera du rouge au vert, indiquant que le contrôle de santé TCP est réussi puisque le port :8090 est désormais ouvert.
Vous devriez maintenant être en mesure d'accéder à DVWA en utilisant le navigateur Firefox via le ZAP Proxy et le WAF en entrant le nom d'hôte ou l'adresse IP publique de votre Test Drive en utilisant le port web standard :80 soit http://X.X.X.X ou quelque chose comme
Vous devriez voir un écran comme celui-ci.
Cliquez sur Créer / Réinitialiser la base de données.
Connectez-vous au DVWA avec l'identifiant par défaut admin / password.
Vous serez maintenant connecté à DVWA en tant qu'administrateur.
Le niveau de sécurité par défaut de DVWA est "Impossible", de sorte qu'il ne présente aucune vulnérabilité. Vous devez régler le niveau sur bas en cliquant sur le menu Sécurité DVWA, en sélectionnant Bas dans le menu déroulant et en cliquant sur soumettre.
Le DVWA est maintenant prêt à être utilisé comme cible de test de vulnérabilité.
Il y a quelques étapes à suivre pour configurer ZAP afin qu'il commence par espionner l'application DVWA et qu'il exécute ensuite une attaque. Nous vous renvoyons aux différentes ressources en ligne pour plus de détails sur la manière de procéder, plutôt que de régurgiter les informations ici.
Lorsqu'il s'agit de configurer le proxy de votre navigateur sur localhost, vous avez déjà effectué les étapes de configuration nécessaires ci-dessus.
Lorsque vous avez effectué l'attaque, vous devriez être en mesure de voir les résultats dans les interfaces graphiques du proxy ZAP et du WAF. Ici, vous pouvez voir l'arbre des vulnérabilités qui a été analysé puis attaqué en tant qu'utilisateur administrateur.
De retour dans la fenêtre du proxy ZAP, vous pouvez voir que les attaques ont reçu une réponse d'erreur 403 de la part du WAF, bloquant leur progression vers le serveur DVWA.
Le WAF joue le rôle qui lui est dévolu, à savoir protéger les attaques contre le serveur d'application.
En plus de pouvoir bloquer des milliers d'attaques de piratage, le WAF est également capable de filtrer certains comportements d'attaques DOS afin qu'ils n'atteignent pas les serveurs web sensibles.
Nous espérons que ce test vous permettra de découvrir la facilité de mise en œuvre du Web Application Firewall ALB-X d'Edgenexus.
Nous vous invitons à nous faire part de vos commentaires et serions heureux de vous aider à mettre en place votre propre implémentation WAF de production.
Nous serions heureux de répondre à vos questions à l'adresse suivante : pre-sales@edgenexus.io
Matériel, logiciel ou même votre propre image en ligne avec un environnement de test complet.
Faites-nous savoir ce dont vous avez besoin ici
MAGASIN D’APPLICATIONS