Comment implémenter la protection des applications WEB et des API avec ZEVENET (WAAP)

PUBLIÉ LE 24 février 2023

Qu'est-ce qu'une application WEB et une protection d'API (WAAP)

La protection des applications Web et des API (WAAP) est une évolution progressive du produit de sécurité ZEVENET, le pare-feu d'application Web (WAF). Le WAAP offre les mêmes fonctionnalités qu'un WAF traditionnel mais protège également les API en plus des applications Web.

Avec l'évolution des services cloud et du SaaS (Software as a Service), la nécessité d'intégrer divers environnements a fait progresser l'utilisation des API, offrant la meilleure solution pour orchestrer tous ces services. Cette fonctionnalité rend le WAAP plus avancé que le WAF, car on peut déployer un WAAP à la périphérie d'un réseau contenant des services publics ou le configurer dans le même environnement avec un ADC.

C'est donc ici que le ZEVENET ADC et le WAAP s'unissent pour travailler ensemble et offrir une protection aux applications Web et aux API avant la livraison d'une application.

Pourquoi un WAAP est requis

Étant donné que l'on peut accéder facilement aux API et aux applications Web sur Internet, la sécurité est une grande préoccupation car des données sensibles sont exposées. Un attaquant peut provoquer une faille de sécurité pour obtenir des informations privées. Ainsi, un WAAP est nécessaire car la sécurité Web traditionnelle ne gère pas les tâches suivantes :

La correspondance des signatures n'est pas suffisante pour la sécurité des applications :
Le contenu des applications Web et des API évolue en permanence. Ainsi, la signature du contenu est difficile à obtenir. Étant donné que le contenu et les API publiés sur le Web ne cessent de changer, le système nécessite un apprentissage constant.

Bloquer le trafic en fonction de l'IP source ou du port de destination n'est pas suffisant :
Les pare-feu traditionnels bloquent les adresses IP et les ports, mais ces informations sont généralement cryptées. Un mécanisme pour déchiffrer, analyser le contenu et rechiffrer est vital. Nous utilisons le mécanisme TLS, de sorte que le WAAP peut offrir un niveau de sécurité plus élevé.

Le trafic HTTP(S) est actuellement le plus utilisé et il peut offrir une complexité dans l'analyse : la plupart du trafic Web est dirigé vers le protocole de couche 7 HTTP(S) du modèle OSI, offrant une complexité dans le comportement du protocole HTTP défini dans le des années 80 aux protocoles modernes utilisés aujourd'hui. Cela oblige la solution de sécurité non seulement à utiliser le mécanisme IPS ou IDS, mais également à pouvoir se protéger contre les attaques sur la couche supérieure du modèle OSI, les protocoles de couche 7 comme HTTP et HTTPS.

Quelles fonctionnalités un WAAP peut offrir qu'un WAF traditionnel ne peut pas

Le WAAP offre des capacités énormes qu'un WAF traditionnel ne peut pas offrir :

Automatisation et apprentissage : Le WAAP est un élément vivant intégré au sein d'un ADC. Cette fonctionnalité de sécurité reçoit des informations et apprend en permanence à l'aide de mécanismes tels que la détection DoS, la détection de bot, la protection du protocole et l'application, entre autres. Le moteur WAAP nécessite un canal pour recevoir les données INPUT, où le moteur WAAP reçoit constamment de nouvelles informations et compare les informations reçues aux données traitées et inspectées.

API sécurisées et microservices : Au quotidien, les ingénieurs construisent des API et des microservices pour offrir des services publics. Le WAAP doit protéger ces endpoints, en tenant compte des informations exposées.

Comment ZEVENET fonctionne comme un WAAP

ZEVENET ADC comprend un module de cybersécurité appelé IPDS (système de prévention et de détection d'intrusion). Ce module offre des fonctionnalités WAAP, une automatisation et un apprentissage pour les WEB et les API. ZEVENET inclut un package appelé zevenet-ipds, et ce package est mis à jour quotidiennement. Ce package dispose de plus de 4 mécanismes pour les applications Web et la protection des API. Ses propriétés sont :

Règles de la liste de blocage

Les listes de blocage font partie d'un mécanisme de sécurité permettant de regrouper le trafic en fonction de la géolocalisation et de différentes sources, comme décrit ci-dessous :

géo_*: Ces listes de blocage incluent les adresses IP et les réseaux basés sur les pays.
TOR_nodes: Cette liste de blocage est obtenue à partir du projet TOR. Ici, nous pouvons trouver les adresses IP sources où le trafic TOR est publié sur Internet.
exploitation web: Les membres de la liste source ont été identifiés comme des exploiteurs Web. Ces attaquants ont tenté d'exécuter plusieurs requêtes contre des serveurs Web pour trouver des vulnérabilités.
ssh_bruteforce: La source incluse est une liste d'attaquants ssh utilisant des techniques de force brute pour obtenir l'utilisateur et le mot de passe du serveur ssh attaqué.
spyware: La ou les sources incluses sont une liste de plages d'adresses IP de logiciels espions et publicitaires malveillants.
procuration: contient TOR et d'autres proxys ouverts.
mail_spammer: La source incluse est une liste basée sur les adresses IP détectées en train d'envoyer du spam.
bad_peers: La source incluse est une liste basée sur des rapports de mauvaises actions en p2p.
wordpress_list: Toutes les adresses IP qui attaquent Joomla, WordPress et d'autres connexions Web avec des connexions Brute-Force.
Réseaux_privés: La source incluse est une liste basée sur toutes les adresses sources IPv4 non routables sur Internet.
mail_list: Toutes les adresses IP qui ont été signalées au cours des dernières 48 heures comme ayant lancé des attaques sur le service Mail, Postfix.
ssh_list: Toutes les adresses IP qui ont été signalées au cours des dernières 48 heures comme ayant lancé des attaques sur le service SSH.
liste_ftp: Toutes les adresses IP qui ont été signalées au cours des dernières 48 heures pour des attaques sur le service FTP.
apache_list: Toutes les adresses IP qui ont été signalées au cours des dernières 48 heures comme ayant lancé des attaques sur le service Apache, Apache-DDOS, RFI-Attacks
CIArmée: Les sources incluses ici sont offertes par le projet CIArmy. Ce projet fournit la source de données obtenue en analysant le trafic basé sur un groupe de sentinelles autour d'Internet.
bogon: La source incluse ici prétend provenir d'une zone de l'espace d'adressage IP réservé mais non encore alloué ou délégué par Internet.

Règles DOS

L'atténuation du déni de service est un ensemble de règles destinées à protéger ou à réduire l'impact des attaques sur un service qui le rend inutilisable en raison d'un nombre écrasant de demandes illégitimes. Le moteur ZEVENET IPDS comprend diverses techniques pour effectuer la protection DoS des applications Web et des API.

Ces règles ont été décrites ci-dessous :

Drapeaux TCP factices:
Dans tout trafic TCP, les paquets TCP suivent un flux connu. Une attaque TCP BOGUS est une attaque où le flux TCP ne suit pas un chemin TCP attendu. Par exemple, le paquet peut suivre un chemin SYN-FIN qui est inattendu, au lieu d'un chemin SYN-ACK. ZEVENET surveille et contrôle le flux TCP. Si un paquet inattendu est reçu, ZEVENET le supprimera.

Limite totale de connexion par IP source:
ZEVENET applique une limite de source basée sur le nombre de requêtes par seconde, et lorsque la limite par IP source est atteinte, ZEVENET supprime les paquets entrants.

Limiter le paquet RST par seconde:
Il s'agit d'une attaque DoS courante dans laquelle l'attaquant tente d'ouvrir un socket TCP et, une fois le paquet de réponse TCP reçu, l'attaquant envoie un paquet TCP RST à l'hôte.

Limite de connexion par seconde:
ZEVENET applique une limite de destination basée sur le nombre de requêtes par seconde. Si la limite par adresse IP de destination est atteinte, ZEVENET supprimera les paquets entrants.

Règles RBL

Une liste noire en temps réel est un système de sécurité utilisé par les serveurs de messagerie pour se protéger contre les spammeurs. Si le serveur de messagerie reçoit une connexion, il capture l'adresse IP source et tente de la résoudre par rapport aux serveurs DNS connus. Si la résolution DNS fonctionne, l'adresse IP source sera détectée comme un attaquant.

ZEVENET a fait évoluer ce mécanisme de sécurité permettant de capturer n'importe quelle adresse IP source dans un certain flux et d'essayer de résoudre l'adresse IP source par rapport à une zone DNS. Chaque zone DNS résout les adresses IP source en fonction de différents comportements. Ces zones sont décrites ci-dessous :

Zone all.rbl.zevenet.com: L'adresse IP source tentera d'être résolue par rapport à toutes les sous-zones incluses dans rbl.zevenet.com.
Zone apache.rbl.zevenet.com: La source incluse dans cette sous-zone fait référence à des attaquants contre des hôtes Apache.
Zone asterisk.rbl.zevenet.com : Les sources incluses dans cette sous-zone font référence à des attaquants contre les hôtes Asterisk.
Zone bruteforcelogin.rbl.zevenet.com: La source incluse dans cette sous-zone fait référence à des attaquants qui ont tenté d'obtenir des utilisateurs et des mots de passe contre divers services hôtes en utilisant des mécanismes de force brute.
Zone ftp.rbl.zevenet.com: La source incluse dans cette sous-zone fait référence à des attaquants contre des hôtes FTP.
Zone mysql.rbl.zevenet.com: La source incluse dans cette sous-zone fait référence à des attaquants contre des hôtes Mysql.
Zone ssh.rbl.zevenet.com : La source incluse dans cette sous-zone fait référence à des attaquants contre des hôtes SSH.
Zone webmin.rbl.zevenet.com : La source incluse dans cette sous-zone fait référence à des attaquants contre l'application Web Webmin.
Zone apachedos.rbl.zevenet.com : La source incluse dans cette sous-zone fait référence à des attaquants contre le serveur Web, Apache, en utilisant le mécanisme de déni de service distribué.
Zone mail.rbl.zevenet.com: La source incluse dans cette sous-zone fait référence à des attaquants contre des hôtes de messagerie.

Règles WAF

ZEVENET inspecte le trafic HTTP(S) de deux manières :

1 – Utilisation de règles prédéfinies basées sur les jeux de règles OWASP (Open Web Application Security Project). Les ensembles de règles inclus dans ZEVENET 6 sont basés sur l'ensemble de règles de base OWASP version 4. Ces règles sont mises à jour quotidiennement. Si un changement se produit dans l'ensemble de règles OWASP, la prochaine mise à jour du package IPDS inclura les changements.

2 - En utilisant des règles obtenues auprès de fournisseurs tiers ou des règles personnalisées conçues par vous, notre client. ZEVENET utilise le support du moteur ModSecurity pour les ensembles de règles tiers ou crée vos propres règles basées sur le langage HTTP dissecteur.

Par défaut, ZEVENET IPDS inclut des paquets de sécurité contre les attaques suivantes :

Injection SQL (SQLi)
XSS (Cross-Site Scripting)
Inclusion de fichiers locaux (LFI)
Inclusion de fichiers à distance (RFI)
Injection de code PHP/Java/Ruby/Perl
Shellshock
Injection de shell Unix
Fixation de session
Script/Scanner/Détection de robots

Les ensembles de règles trouvés dans ZEVENET 6 incluent :

DEMANDE-905-COMMON-EXCEPTIONS
Ces règles sont utilisées comme mécanismes d'exception pour supprimer les faux positifs courants qui peuvent être rencontrés.
DEMANDE-911-MÉTHODE-APPLICATION
Méthodes de requête autorisées.
DEMANDE-913-DÉTECTION-SCANNER
Vérifie les scanners tels que les robots d'exploration, les bots, les scripts, etc.
DEMANDE-920-APPLICATION DU PROTOCOLE
Valide les requêtes HTTP en éliminant un grand nombre d'attaques de la couche application.
DEMANDE-921-PROTOCOLE-ATTAQUE
Vérifie les attaques de protocole.
DEMANDE-930-APPLICATION-ATTAQUE-LFI
Vérifie les attaques d'application à l'aide de l'inclusion de fichiers locaux (LFI).
DEMANDE-931-APPLICATION-ATTAQUE-RFI
Vérifie les attaques d'applications à l'aide de l'inclusion de fichiers à distance (RFI).
DEMANDE-932-APPLICATION-ATTAQUE-RCE
Vérifie les attaques d'application à l'aide de l'exécution de code à distance (RCE).
DEMANDE-933-APPLICATION-ATTAQUE-PHP
Vérifie les attaques d'applications à l'aide de PHP.
DEMANDE-934-APPLICATION-ATTAQUE-GÉNÉRIQUE
Recherchez les attaques d'application à l'aide de Node.js, Ruby et Perl.
DEMANDE-941-APPLICATION-ATTAQUE-XSS
Vérifie les attaques d'applications à l'aide de XSS.
DEMANDE-942-APPLICATION-ATTAQUE-SQLI
Vérifie les attaques d'applications à l'aide de SQL Injection.
DEMANDE-943-APPLICATION-ATTAQUE-SESSION-FIXATION
Vérifie les attaques d'application à l'aide de la fixation de session.
DEMANDE-944-APPLICATION-ATTAQUE-JAVA.
Vérifie les attaques d'applications à l'aide de Java.

Le moteur IPDS est un mécanisme de renseignement sur les menaces pour les applications Web et la protection des API. Il est mis à jour quotidiennement via le paquet zevenet-ipds, qui fonctionne comme le cœur du moteur, en gardant ce moteur à jour avec les règles ZEVENET et celles personnalisées par le client.

Cet ensemble de règles de base zevenet-ipds utilise divers mécanismes pour créer ces règles de sécurité, comme le croisement de données tierces, l'analyse de journaux sentinelles ou l'analyse de données volumineuses par rapport à des informations privées. Si vous identifiez que l'ensemble de règles de base de ZEVENET IPDS inclut certaines adresses IP ou règles sources comme faux positifs, contactez-nous et nous serons heureux de résoudre le problème dès que possible.

Partager sur:

Documentation sous les termes de la licence de documentation libre GNU.

Cet article a-t-il été utile?

Articles Relatifs